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

From: "Charles Q. Shen" <[email-masked]>
Date: Tue, 02 Jul 2002 14:03:11 +0800

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: [email-masked] [mailto:[email-masked]]
> > Sent: 28 June 2002 11:08
> > To: Hancock, Robert; [email-masked]
> > 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:[email-masked]]
> > Sent: 2002年6月28日 17:33
> > To: Hancock, Robert; Kan Zhigang (Nokia-RD/Beijing); [email-masked]
> > 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: [email-masked]'; [email-masked]
> > > 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: [email-masked] [mailto:[email-masked]]
> > > > Sent: 28 June 2002 10:10
> > > > To: Hancock, Robert; [email-masked]
> > > > 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:[email-masked]]
> > > > Sent: 2002年6月28日 16:28
> > > > To: Kan Zhigang (Nokia-RD/Beijing); [email-masked]
> > > > 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: [email-masked] [mailto:[email-masked]]
> > > > > Sent: 28 June 2002 08:43
> > > > > To: Hancock, Robert; [email-masked]
> > > > > 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:[email-masked]]
> > > > > Sent: 2002年6月27日 19:02
> > > > > To: Kan Zhigang (Nokia-RD/Beijing); [email-masked]
> > > > > Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band
> > > > >
> > > > >
> > > > > Hi Zhigang,
> > > > >
> > > > > Please see inline:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > > Sent: 27 June 2002 11:53
> > > > > > To: Hancock, Robert; [email-masked]
> > > > > > 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:[email-masked]]
> > > > > > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 2 Jul 2002 10:12:47 +0100

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

> From: Charles Q. Shen [mailto:[email-masked]]
> Sent: 02 July 2002 07:03
> To: Hancock, Robert; [email-masked]'; [email-masked]
> under my control 
> > > Sent: 2002å¹´6æoe^28æ-¥ 17:33
> > > > > Sent: 2002å¹´6æoe^28æ-¥ 16:28
> > > > > > Sent: 2002å¹´6æoe^27æ-¥ 19:02
> > > > > > > Sent: 2002å¹´6æoe^24æ-¥ 19:47
> > > > > > > To: NSIS
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: "Charles Q. Shen" <[email-masked]>
Date: Wed, 03 Jul 2002 11:14:50 +0800

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

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

>Permission is hereby granted to pass the contents of this communication to 
>third parties and any restrictions regarding confidentiality do not apply.

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 3 Jul 2002 14:51:24 +0100

hi Charles,

a pleasure to un-spread confusion. one comment:

[snip]
> misunderstood your meaning.) So what do you mean here 

One scenario could be:
*) end system in a v4 world sends out an NSIS message (e.g. a sender initiated reservation) and fills in the flow information saying what packets the reservation is for;
*) message makes its way through the network following normal L3 routing, i.e. (hopefully) the same route as the data packets;
*) message hits a SIIT (v4-v6 translator), which will do header translation on the data packets; in order to request the resource for the right flow, the SIIT box has to rewrite the flow definition correspondingly.

To clarify, I'm just raising this as an example of the sort of thing that could be done, not saying it definitely should be. Really, I'm just working through the question of whether there might be reasons for NSIS messages to have flow identification not as part of the opaque resource management information (this is one), and for them to be processed for non resource related reasons. (Note that this particular case is entirely independent of the mobile aspects, although mobility solutions might require similar message processing.)

[snip snip snip snip]

Cheers,

Robert H.