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

["Charles Q. Shen" <[e-mail]>]

Hi, Robert

Thanks for your reply. please see comments in line.

At 10:12 2002-7-2 +0100, Hancock, Robert wrote:
>Content-Type: text/plain;
>         charset="iso-8859-1"
>X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id 
>FAA25345
>
>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.

Ok.

>*) There might be reasons to process NSIS messages other than resource 
>management. One reason might be to address-translate a flow definition.

This is probably where I would like you to elaborate. So far my impression 
is that we haven't reached a sole conclusion for the addressing issue of a 
flow especially in the mobile case. (correct me if I am wrong or have 
misunderstood your meaning.) So what do you mean here "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.)

This is exactly what I understand.


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

Agree.


>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_.

Can't agree more.


>Is this any clearer?

See above :)

BR/ Charles



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


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