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

From: [email-masked]
Date: Thu, 27 Jun 2002 18:52:39 +0800

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? And must it install soft states in each router it passed through based on per-flow or per-class-flow? 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? 

I don't know why "the initial goal of NSIS is to concentrate mainly on the in-band case". 

BR/Kan Zhigang

-----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: Thu, 27 Jun 2002 12:02:08 +0100

Hi Zhigang,

Please see inline:

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

> mainly on the in-band case". 

[reh] that's a WG chair/AD question.

Cheers,

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

---

From: [email-masked]
Date: Thu, 27 Jun 2002 14:07:30 +0300

Hi Kan,

> mainly on the in-band case". 

This was part of the chartering process.  NSIS is chartered to
solve in-band signaling.  Out of band signaling needs could
be documented, but it is doubtful that NSIS will try to solve
out-of-band signaling, or at least not until there is 
rechartering of the WG.

John

---

From: [email-masked]
Date: Fri, 28 Jun 2002 15:42:30 +0800

Hi Robert,

Q1: "Node" used in your terminology can be a router, an end host or a server, right? In the case of distributed RMF, must each node have the resource management function in a NSIS domain?

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.

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,

Cheers,

Robert H.

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 28 Jun 2002 10:21:58 +0200

Hi 

In case of distributed RMF, each RMF function may be co-located 
(included) within each node that uses NSIS signaling.
Each node might be NI, NF or NR.
Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 28, 2002 9:43 AM
To: [email-masked]; [email-masked]
Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band

Hi Robert,

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,

Cheers,

Robert H.

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 28 Jun 2002 09:27:36 +0100

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

> Sent: 28 June 2002 08:43
> 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...)

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

---

From: [email-masked]
Date: Fri, 28 Jun 2002 16:41:49 +0800

Hi,

"NSIS Entity (NE) - the function within a 'NODE' which implements an NSIS protocol. "

I refered to the "NODE" in the above definition, and can it be a router, a host, a server or whatever a new concept thing? In ohter words, may NI, NF and NR be a router, a server or a host?

Is there any special requirements on network equipments in a existing netwok domain if it will become a NSIS domain?

BR/Kan Zhigang
-----Original Message-----
From: ext Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: 2002年6月28日 16:22
To: Kan Zhigang (Nokia-RD/Beijing); [email-masked];
[email-masked]
Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band

Hi 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 28, 2002 9:43 AM
To: [email-masked]; [email-masked]
Subject: RE: [NSIS] New framework draft: In-Band & Out-of-Band

Hi Robert,

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,

Cheers,

Robert H.

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 28 Jun 2002 10:03:47 +0100

hi,

any node which processes NSIS messages has an NE inside it which does that processing. we have given NEs different names depending on what role they are playing within the protocol.

if you accept that NSIS messages have to follow the data path, that restricts what sorts of nodes can have NEs inside them. you can easily think of scenarios where NI/NF/NR could be in router or hosts, but not servers. (although I suppose you could backhaul NSIS messages to a central server if you wanted to, we just aren't defining a backhaul mechanism to do this.)

i don't believe there are any special requirements on existing network equipments to use NSIS in a domain (or rather, we have requirements - i think - to allow incremental deployment and use of NSIS). obviously, to use NSIS in the first place, you'll need to have _some_ equipment that processes the messages.

(terminology is never easy. suggestions are welcome.)

cheers,

robert h.

> Sent: 28 June 2002 09:42
> To: [email-masked]; Hancock, Robert; 
> [email-masked]
> I refered to the "NODE" in the above definition, and can it 
> be a router, a host, a server or whatever a new concept 
> thing? In ohter words, may NI, NF and NR be a router, a 
> server or a host?
> 
> Is there any special requirements on network equipments in a 
> existing netwok domain if it will become a NSIS domain?
> 
> BR/Kan Zhigang
> host or a server, right? In the case of distributed RMF, must

---

From: [email-masked]
Date: Fri, 28 Jun 2002 17:09:43 +0800

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.

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 28 Jun 2002 10:30:44 +0100

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.

> Sent: 28 June 2002 10:10
> 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
> 
> 
> 
> 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 ...
> 
> [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.
> 
> [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:
> 2) even if a node does process NSIS messages, it might do so 
> for reasons not associated with resource management.
> 
> > 
> 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.
> 
> 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.
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 28 Jun 2002 10:32:51 +0100

hi - minor correction - in 3rd sentence below, s/nodes/hosts/.

r.

> From: Hancock, Robert 
> Sent: 28 June 2002 10:31
> To: [email-masked]'; [email-masked]
> 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:
> 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.
>

---

From: [email-masked]
Date: Fri, 28 Jun 2002 12:42:40 +0300

Hi Kan,

> to deploy it in the future.

For IPv6, RFC 2460 defines the following terms:

   node        - a device that implements IPv6.

   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.  [See Note below].

   host        - any node that is not a router.  [See Note below].

   Note: it is possible, though unusual, for a device with multiple
   interfaces to be configured to forward non-self-destined packets
   arriving from some set (fewer than all) of its interfaces, and to
   discard non-self-destined packets arriving from its other interfaces.
   Such a device must obey the protocol requirements for routers when
   receiving packets from, and interacting with neighbors over, the
   former (forwarding) interfaces.  It must obey the protocol
   requirements for hosts when receiving packets from, and interacting
   with neighbors over, the latter (non-forwarding) interfaces.

For me, this is the easier way to think about NSIS entities.  More specifically,
An NSIS entitity as most likely a protocol instance of the NSIS protocol
in a node.  Under most circumstances, I don't see a single NSIS entity 
that would be distributed over multiple nodes.

I would imagine that NSIS entities would most likely be in the ingress
and egress points of an administrative domain, for example.

John

---

From: [email-masked]
Date: Fri, 28 Jun 2002 18:07:30 +0800

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

r.

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 28 Jun 2002 11:29:42 +0100

Hi Zhigang,

If you have an NSIS-unaware router on the path, in the time honoured phrase, "your mileage may vary". There are two aspects:
*) as a protocol, NSIS has to operate correctly even if some intermediate nodes are not NSIS aware. this has quite significant implications for security aspects, for example. 
*) 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.

i'll look forward to the 'modes of operation' questions!

cheers,

robert h.

> Sent: 28 June 2002 11:08
> 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
>

---

From: [email-masked]
Date: Fri, 28 Jun 2002 13:34:44 +0300

Hi Robert,

> If you have an NSIS-unaware router on the path, in the time 
> honoured phrase, "your mileage may vary". There are two aspects:
> *) as a protocol, NSIS has to operate correctly even if some 
> intermediate nodes are not NSIS aware. this has quite 
> significant implications for security aspects, for example. 
> *) 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.

I actually think that it is practical that intermediate routers
are NSIS-unware.  The most important parts of an NSIS network
would be the ingress & egress points.  Assuming one did a
competent job of network configuration & provisioning, this may
be enough in many cases.

Also, it would be entirely reasonable to (and entirely out of scope
of NSIS to standardize) use some protocol for communicating with resource
management, such as a bandwidth broken, if this was something
that you wanted to do.

John