RE: [NSIS] New framework draft: In-Band & Out-of-Band

["Hancock, Robert" <[e-mail]>]

Hi Charles,

Sometimes my over-careful use of language may cause more confusion than it prevents. Formally:
*) An NSIS-aware node is defined as anything which processes an NSIS message for whatever reason.
*) There might be reasons to process NSIS messages other than resource management. One reason might be to address-translate a flow definition. 
*) There might be several types of resource being managed, and not all nodes will do all of them. For example, a 'normal' interior router probably _should_ ignore NSIS messages which are about signalling for firewall pinholing. (But note: we aren't certain if the differences between different types of resource will be opaque to NSIS or not. See section 4.5.3.)

Having said that, I would not be surprised if 99% of NSIS nodes do resource management for QoS for the forseeable future. But that's just a personal view about how NSIS might be used, not a statement about how the protocol should be designed.

The basic point we are trying to emphasise is that we should strictly avoid identifying "NSIS aware node" = "router that does QoS management". It's true that NSIS is about resource signalling; but the emphasis is that NSIS is about _signalling_, not about _resources_.

Is this any clearer?

Cheers,

Robert

> -----Original Message-----
> From: Charles Q. Shen [mailto:[e-mail]]
> Sent: 02 July 2002 07:03
> To: Hancock, Robert; '[e-mail]'; [e-mail]
> Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band
> 
> 
> Hi Robert,
> 
> >*) if an intermediate node is NSIS unaware, or is NSIS aware 
> but doesn't 
> >do any management for some particular resource, then there's 
> nothing NSIS 
> >can do directly to help the resource management at that 
> node. That doesn't 
> >stop you using some other technique to control the resource 
> at that node 
> >(some variant of SNMP or COPS or RMD or whatever), but so 
> far as NSIS is 
> >concerned, all of that would be hidden inside your RMF 
> implementation.
> 
> Do you mean an NSIS aware node is at least doing something regarding 
> certain resources, although it might not be managing a 
> particular resource 
> in question, as we use resource as a general term for serval 
> items? What 
> actually confused me is I remember you said before:
> 
> 2) even if a node does process NSIS messages, it might do so 
> for reasons 
> not associated with resource management.
> 
> So can you elaborate on this point, if NSIS is all about resource 
> signaling? (Unless you are talking about for example, in the 
> case of NI and 
> NR you may not have a RMF associated with it, but even in this case 
> virtually the processing of NSIS message is still one segment 
> in the whole 
> resource management picture.)
> 
> BR/Charles
> 
> 
> >i'll look forward to the 'modes of operation' questions!
> >
> >cheers,
> >
> >robert h.
> >
> >ps apologies about my email disclaimer, it's not entirely 
> under my control 
> >to fix it, though we're doing what we can. i am aware that i 
> am sending 
> >this email to a public mailing list ...
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: 28 June 2002 11:08
> > > To: Hancock, Robert; [e-mail]
> > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band
> > >
> > >
> > > Hi Robert,
> > >
> > > Till now, I understood the definition of NE. Thank you. :-)
> > > It is right that we must have the common understanding of the
> > > terms, so we can continue the discussion further.
> > >
> > > One more thing, If one/more router(s) on the data path does
> > > not support RMF (as you said: if you have a distributed
> > > approach to resource management, i guess we would typically
> > > expect most nodes would have a resource management
> > > responsibility, but there's no requirement for every node to
> > > do something with resource management.), how about in this
> > > case? Can the QoS of data on this path be affected by 
> these routers?
> > >
> > > Next I would like to discuss the relationship of modes of
> > > NSIS protocol operation such as how the end-to-end,
> > > edge-to-edge, and end-to-edge signaling take effects when the
> > > per-flow/per-class-flow traffic is initiated by a host.
> > >
> > > Nice weekend.
> > >
> > > BR/Kan Zhigang
> > >
> > > -----Original Message-----
> > > From: ext Hancock, Robert [mailto:[e-mail]]
> > > Sent: 2002å¹´6æoe^28æ-¥ 17:33
> > > To: Hancock, Robert; Kan Zhigang (Nokia-RD/Beijing); [e-mail]
> > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band
> > >
> > >
> > > hi - minor correction - in 3rd sentence below, s/nodes/hosts/.
> > >
> > > r.
> > >
> > > > -----Original Message-----
> > > > From: Hancock, Robert
> > > > Sent: 28 June 2002 10:31
> > > > To: '[e-mail]'; [e-mail]
> > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band
> > > >
> > > >
> > > > Hi Zhigang,
> > > >
> > > > Apologies for maybe informal language. By 'box' I really mean
> > > > typically a physical thing you plug into a power supply, with
> > > > wires carrying packets into and out of it. So, usually it's a
> > > > host or a router. If signalling only follows the data path
> > > > (which is considered at the router level, not the network
> > > > level), the only relevant nodes can be the data flow
> > > > endpoints, and the only relevant routers can be the routers
> > > > the flow passes through.
> > > >
> > > > We've tried to describe things in terms of signalling going
> > > > between signalling entities rather than hosts/routers and so
> > > > on; one of the goals of this is to aim for concepts and
> > > > terminology to describe the signalling that are re-usable
> > > > if/when we subsequently think about signalling paths that are
> > > > less constrained.
> > > >
> > > > It may be (I get the impression) that the level of
> > > > abstraction in the framework makes it hard to get a grip on.
> > > > I'm not sure what would be the best way to handle this (maybe
> > > > some concrete example scenarios or something).
> > > >
> > > > We didn't want to make all the definitions very concrete,
> > > > since that implies building in assumptions about particular
> > > > application domains. Specifically, we have two potential
> > > > degrees of freedom about NSIS applicability which we've tried
> > > > to reflect by using more abstract language:
> > > > *) what sort of resources are signalled for
> > > > *) what sort of signalling paths are traversed
> > > > Currently, the first is in scope and the second not. I hope
> > > > we can avoid too long confusion about the
> > > > node/entity/network/whatever issue, because if we can't,
> > > > we'll probably be encouraged to re-write everything in terms
> > > > of routers and hosts, which will make any future extension to
> > > > other cases much harder.
> > > >
> > > > Cheers,
> > > >
> > > > Robert H.
> > > >
> > > > ps apologies about my email disclaimer, it's not entirely
> > > > under my control to fix it, though we're doing what we can. i
> > > > am aware that i am sending this email to a public 
> mailing list ...
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]]
> > > > > Sent: 28 June 2002 10:10
> > > > > To: Hancock, Robert; [e-mail]
> > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band
> > > > >
> > > > >
> > > > > Hi Robert,
> > > > >
> > > > > I am more confused about 'node' is for 'box', but what in the
> > > > > box, a part of netwok or a whole network or whatever? Does
> > > > > the data pass through the box? How to understand the data
> > > > > path, based on per-router or per-network?  Is NSIS Framework
> > > > > independent of the true networks and is it only abstract
> > > > > concept over the different environments? I cannot image how
> > > > > to deploy it in the future.
> > > > >
> > > > > BR/Kan Zhigang
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: ext Hancock, Robert [mailto:[e-mail]]
> > > > > Sent: 2002å¹´6æoe^28æ-¥ 16:28
> > > > > To: Kan Zhigang (Nokia-RD/Beijing); [e-mail]
> > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band
> > > > >
> > > > >
> > > > > Hi Zhigang,
> > > > >
> > > > > Please see inline below.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Robert H.
> > > > >
> > > > > ps apologies about my email disclaimer, it's not entirely
> > > > > under my control to fix it, though we're doing what we can. i
> > > > > am aware that i am sending this email to a public 
> mailing list ...
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail] [mailto:[e-mail]]
> > > > > > Sent: 28 June 2002 08:43
> > > > > > To: Hancock, Robert; [e-mail]
> > > > > > Subject: RE: [NSIS] New framework draft: In-Band & 
> Out-of-Band
> > > > > >
> > > > > >
> > > > > > Hi Robert,
> > > > > >
> > > > > > Q1: "Node" used in your terminology can be a router, an end
> > > > > > host or a server, right?
> > > > >
> > > > > [reh] yes, in the broadest sense ('node' is a fancy name for
> > > > > 'box'). if you respect the 'on-path' restriction, a node that
> > > > > processes NSIS signalling must be on the data path, which
> > > > > probably rules out the 'server' case.
> > > > >
> > > > > > In the case of distributed RMF, must
> > > > > > each node have the resource management function in a
> > > NSIS domain?
> > > > >
> > > > > [reh] if you have a distributed approach to resource
> > > > > management, i guess we would typically expect most nodes
> > > > > would have a resource management responsibility, but there's
> > > > > no requirement for every node to do something with resource
> > > > > management. in particular:
> > > > > 1) not every node has to process NSIS messages (cf. RSVP
> > > > > operation over non-RSVP clouds)
> > > > > 2) even if a node does process NSIS messages, it might do so
> > > > > for reasons not associated with resource management.
> > > > >
> > > > > >
> > > > > > Q2: The RMF is responsible for all network provisioning and
> > > > > > resource allocation  functions, and "some" of the state
> > > > > > management is an RMF responsibility. How about the 
> "other" of
> > > > > > the state management, and it is refered to the state
> > > > > > management mechanism of NSIS related with "Refresh" message?
> > > > > > If so, what relationship between these two parts of state
> > > > > > management? Is it out of the scope of NSIS? I hope 
> answer is no.
> > > > >
> > > > > [reh] this is a hard question to answer, and a hard question
> > > > > in general.
> > > > >
> > > > > 1. It's clear that to do resource management, you need to
> > > > > store some state information. That information might be at
> > > > > the flow level, or some 'resource class' level, or something
> > > > > else. Because the state you need to store depends on the
> > > > > resource you are trying to manage and the precision with
> > > > > which you need to manage it, we don't think NSIS can define
> > > > > how this is done.
> > > > >
> > > > > 2. You also need state to make a protocol operate correctly.
> > > > > This could include all (or none) of:
> > > > > *) information about how to reverse-path route 
> messages for a flow
> > > > > *) information about who to send an acknowledgement 
> to and when
> > > > > *) information about when to send a refresh message
> > > > > *) information about who was authenticated when a
> > > > reservation was made
> > > > > *) and so on
> > > > > This is all in NSIS scope to worry about. Most of it 
> is per-flow.
> > > > >
> > > > > 3. The relationship between these two types of state is
> > > > > something we discussed, but only in outline. I think a basic
> > > > > design goal could be stated as:
> > > > > "It should be possible to use [a|the] NSIS protocol in such a
> > > > > way that it only requires the minimum of state storage, in
> > > > > particular no more than the resource management mechanism
> > > > > that it is supporting." It's then (I think) mainly a job for
> > > > > the implementor to do both aspects of state management in an
> > > > > economical way (in particular, without duplication). So, I
> > > > > think we need to consider the possible interactions between
> > > > > the different parts of state management, and make sure they
> > > > > get reflected as goals for NSIS design in terms of
> > > > > flexibility and general usefulness of the protocol, but
> > > > > without defining details of exactly how the different types
> > > > > of state interact.
> > > > >
> > > > > This is actually a special case of a more general issue. Look
> > > > > also at draft-braden-2level-signal-arch-00.txt where there is
> > > > > the related question of the split between CSTP and ALSP. The
> > > > > general point is that we almost certainly can't have a pure
> > > > > structure of independent layers (I would expect the ALSP-like
> > > > > upper layer to hook into the operation of the lower layer
> > > > > quite intimately rather than the other way round, but that's
> > > > > more of a protocol design issue). The state management issue
> > > > > is just one aspect of this.
> > > > >
> > > > > So, I think the answer to your question is "yes and no" (if
> > > > > you see what I mean...)
> > > > >
> > > > > >
> > > > > > BR/Kan Zhigang
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Hancock, Robert [mailto:[e-mail]]
> > > > > > Sent: 2002å¹´6æoe^27æ-¥ 19:02
> > > > > > To: Kan Zhigang (Nokia-RD/Beijing); [e-mail]
> > > > > > Subject: RE: [NSIS] New framework draft: In-Band & 
> Out-of-Band
> > > > > >
> > > > > >
> > > > > > Hi Zhigang,
> > > > > >
> > > > > > Please see inline:
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail] [mailto:[e-mail]]
> > > > > > > Sent: 27 June 2002 11:53
> > > > > > > To: Hancock, Robert; [e-mail]
> > > > > > > Subject: RE: [NSIS] New framework draft: In-Band 
> & Out-of-Band
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > In the draft about In-Band & Out-of-Band:
> > > > > > >
> > > > > > >  "In-band signaling means that the path followed 
> by the user
> > > > > > > data packets is the same as the path followed by signaling
> > > > > > > messages. In other words, the signaling and data paths are
> > > > > > > identical. Out-of-band signaling means that the 
> path followed
> > > > > > > by signaling messages might be different from the 
> path used
> > > > > > > by the user data packets. "
> > > > > > >
> > > > > > > So in-band signaling is same as RSVP's operation mode?
> > > > > >
> > > > > > [reh] basically yes, from a topological ("where the messages
> > > > > > go") point of view.
> > > > > >
> > > > > > > And
> > > > > > > must it install soft states in each router it 
> passed through
> > > > > > > based on per-flow or per-class-flow?
> > > > > >
> > > > > > [reh] that's one reasonable way for it to work. see 
> 4.4 about
> > > > > > general state management issues; there are several different
> > > > > > sorts of state and several different ways to manage 
> them. and
> > > > > > some of the state management is an RMF responsibility.
> > > > > >
> > > > > > > I think that it may be
> > > > > > > better if in-band signaling is used in access network and
> > > > > > > out-of-band signaling is used in backbone 
> networks (i.e. the
> > > > > > > out-of-band signaling is used for communcation 
> between RMFs
> > > > > > > which are responsible for the "resource" management
> > > > > > > independent of concrete user traffic in control plane). Is
> > > > > > > resource reservation really needed in backbone 
> network now or
> > > > > > > in the future?
> > > > > >
> > > > > > [reh] that's a good question. however, in our framework we
> > > > > > tried hard to avoid saying that NSIS would work in 
> particular
> > > > > > ways in particular network parts. (ideally, I think there
> > > > > > should be implementation and deployment flexibility within
> > > > > > the protocol to allow this.)
> > > > > >
> > > > > > >
> > > > > > > I don't know why "the initial goal of NSIS is to 
> concentrate
> > > > > > > mainly on the in-band case".
> > > > > >
> > > > > > [reh] that's a WG chair/AD question.
> > > > > >
> > > > > > >
> > > > > > > BR/Kan Zhigang
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Robert H.
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: ext Hancock, Robert 
> [mailto:[e-mail]]
> > > > > > > Sent: 2002å¹´6æoe^24æ-¥ 19:47
> > > > > > > To: NSIS
> > > > > > > Subject: [NSIS] New framework draft
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > A group of us who were involved in past NSIS framework
> > > > > > > activities got together after the interim meeting to put
> > > > > > > together a joint framework document in the form 
> of an all-new
> > > > > > > individual submission. It (roughly) follows the structure
> > > > > > > that was introduced and refined at that meeting.
> > > > > > >
> > > > > > > 
> ==============================================================
> > > > > > > ============
> > > > > > > Abstract
> > > > > > >
> > > > > > >    The NSIS working group is considering protocol
> > > > developments in
> > > > > > >    signaling for resources for a traffic flow along its
> > > > > path in the
> > > > > > >    network. The requirements for such signaling are being
> > > > > > > developed in a
> > > > > > >    separate document; This Internet Draft proposes a
> > > > > framework for
> > > > > > >    such signaling. This initial version provides 
> a model for
> > > > > > > describing
> > > > > > >    the entities that take part in the signaling and the
> > > > > > ways in which
> > > > > > >    they can be used in different modes of 
> operation. It also
> > > > > > > discusses
> > > > > > >    the overall structure of such a signaling protocol.
> > > > > Finally, it
> > > > > > >    considers the possible interactions of NSIS signaling
> > > > > with other
> > > > > > >    protocols and functions, including security issues.
> > > > > > > 
> ==============================================================
> > > > > > > ============
> > > > > > >
> > > > > > > While it works its way through the i-d editor 
> queue, you can
> > > > > > > find a copy here:
> > > > > > > 
> http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt
> > > > > > >
> > > > > > > Comments are welcome. There is a list of open issue
> > > > > > > highlights in section 3.
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Robert Hancock
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.