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

[[e-mail]]

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月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月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月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月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
> > > > 
> > > 
> > 
> 

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis