Subject: RE: [NSIS] RE: Independence of signalling and data path

From: "Chen, Weijing" <[email-masked]>
Date: Tue, 29 Jan 2002 12:24:52 -0600

Very well put, Ilya.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2002 11:45 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: [NSIS] RE: Independence of signalling and data path 

Marcus, 

Let me add my 2cents into this discussion:

It looks to me that this discussion got very heated because it is at the
very border between general QoS signaling and specific QoS technology in use
(by the domain). The fact that you mentioned such terms as "Controller" and
"BB" indicates to me that you have a particular technology in mind that
based on this kind of entities. Tell me how the node at the edge of the RSVP
or DiffServe domain can get such an idea as a BB that governs the
neighboring domain. On the other hand the framework advocated by Georgios
somewhat implies the use of the hop-by-hop QoS technology (and probably for
this reason is opposed by some people including myself) that relies on
signaling and data path being the same.
The way to resolve this conflict in my mind is something along the following
lines:
1. The general NSIS signaling being used between the host and the edge and
between the edges of the neighboring domains (based on different QoS
technology) should follow the same path as data (or lay out the path for the
data if you wish).
2. It is up to the edge nodes that understand used within domain QoS
technology to communicate to the BB or controller and translate NSIS generic
signaling into something specific for this domain. Obviously the generic
NSIS signaling has to be recreated at the domain egress edge.
3. In this scenario the host can be enabled with the particular QoS
technology and use specific signaling for communication with the first
domain or can use generic NSIS signaling.
4. The communication between neighboring domains using the same QoS
technology can be done in the specific for the technology fashion though
translation to NSIS and back will be always available if for whatever reason
those domains prefer it.

In other words I am suggesting the following global analogy: 
If you view the domain with a QoS technology as a virtual router than NSIS
signaling used between those routers follows the same path as data. What
happens within the router is not a NSIS business.

Ilya Freytsis

Date: Tue, 29 Jan 2002 11:36:05 +0100
From: Marcus Brunner <[email-masked]>
Reply-To: [email-masked]
To: "Georgios Karagiannis (ELN)" <[email-masked]>
Cc: [email-masked]
n.se>
Subject: [NSIS] RE: Independence of signalling and data path (was RE: [NSIS]
Two			kindsof  requirements)

Georgios,

see inline

--On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
<[email-masked]> wrote:

> Hi Marcus
>
>
> [MB]>> So, I think you much in line with that req. The protocol
> [MB]>> from host to BB does not depend on the data path
> [MB}>> completly. What the constrain for the
> [MB]>> communication are is a different question.
>
> I will repeat what was already said in my previous e-mail:
>
> This is only true when the following CONSIDEARTIONS are
> fulfilled:
>
> * BB's or QoS controllers are used;

-> QoS controllers are no BBs in our understanding, the hop by hop 
signalling is a special case, where each hop has a QoS controller and QoS 
initiator functionality runing.

> * the end-host should know the address of the first hop Bandwidth Broker;

An end-host needs to know quite a bit of servers/nodes anyway. I even think 
there are solutions (e.g. AAA servers), where the first hop router is 
forwarding the signalling messages to the right place.

> * the BBs should be aware (know) the addresses of neighboring BBs;

Sure, you need interdoamin routing anyway.

> * BB's or QoS controllers should be able to relate
>    the QoS signaling to the data path;
>

yes true, I think this is the core functionality of a signalling protocol. 
Only depends on the information available in the signaling message.

>
>  In GENERAL the above CONSIDERATIONS are very difficult to
>  fulfill. Please note that we need a NSIS protocol that can
>  be applied for GENERAL cases. Of course YOUR
>  SCENARIO, but OTHER TYPES as well will be INCLUDED.
>

IMO, with the QoS initator and QoS controller framework we excaclty target 
a more general case then the hop-by-hop signalling.

> Thus, in GENERAL the path followed by signaling
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
>

No, I do not agree.

>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.

Not necessarly (but normally packet with the same destination likely take 
the same path)

> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
> [MB]>> And whether, the
> [MB]>> protocol work
> [MB]>> between ehost, eedge, ehop, all of them can be controllers
> [MB]>> and initiators
> [MB] on the other side. So they do not require data and signalling
> [MB] on the same path.
>
> What do you mean, would you like to have a NSIS protocol version
> that starts at one hop router and terminates at the next first hop router.
> This protocol will be very slow, very complex, and in my opinion
> not useful!
>

You have to be more specific on slow and complex.
If you mean with slow the signalling delay (I think you are better of not 
performing some actions in each hop)

The complextity in terms CPU heavily depends on the complexity of the state 
machine, which defionitly not defined yet. But you are definitly right, 
that it needs to be simple.

Marcus

> Best regards,
> Georgios

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

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

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 29 Jan 2002 17:26:19 -0500

Yes, Paulo. That is exactly what I am proposing. 

I can add that resource management entities of the same nature (technology)
within domain MAY use NSIS to communicate directly to each other as a
protocol of choice but it is really up to that particular technology to
decide (it may use SIP if it finds that SIP fits better) and should not
effect NSIS protocol(s). The same can be said about interaction between
hosts enabled with unique for the domain QoS technology (they may have even
special hardware required for this).

Ilya

-----Original Message-----
From: Paulo Mendes [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 5:14 PM
To: Freytsis, Ilya
Cc: [email-masked]'; [email-masked]'
Subject: Re: [NSIS] RE: Independence of signalling and data path

Hello

Well.. This seems more clear to me, but I still have some doubts :).

So, does this means that NSIS only needs two versions: host-edge and
edge-edge? And that the hop-hop inside each domain is a concern of each
network provider and not NSIS?

If I understood correctly resources management entities inside each
domain (BB or other) don't need a host-host NSIS *version* to
communicate, being the inter-domain communication made by the edge-edge
NSIS *version*. Is this right?

Cheers
Paulo

--
| Paulo Mendes
| www.cs.columbia.edu/~mendes

---

From: "Chen, Weijing" <[email-masked]>
Date: Tue, 29 Jan 2002 16:54:26 -0600

Agreed here with Ilya. This is always our line of thinking about what NSIS
is.

And I would like to bring the following diagram again:

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
          user/             domains              user/
          network           (intra)              network
          NSIS                                   NSIS

and with NSIS applicable for inter-domain:

|----|   |-----|            |-----|   |----|
|ehop|<->|ehop |            |ehop |<->|ehop|
|----|   |-----|            |-----|   |----|
         |     |            |     |
         |-----|            |-----|
         |glue |            |glue |
         |-----|            |-----|
         |     |            |     |
         |-----|            |-----|
         |eedge|<---------->|eedge|
         |-----|            |-----|   
hop       edge                edge      hop
                  domains             
                  (inter)
                   NSIS

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2002 4:26 PM
To: 'Paulo Mendes'; Freytsis, Ilya
Cc: [email-masked]'; [email-masked]'
Subject: RE: [NSIS] RE: Independence of signalling and data path

Ilya

-----Original Message-----
From: Paulo Mendes [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 5:14 PM
To: Freytsis, Ilya
Cc: [email-masked]'; [email-masked]'
Subject: Re: [NSIS] RE: Independence of signalling and data path

Hello

Cheers
Paulo

---

From: [email-masked]
Date: Tue, 29 Jan 2002 18:11:02 -0500

Hi:

IMHO, an important point to be stressed when talking inter-domain is that only "host-specific" interdomain signalling (of course, if required) needs to be covered by NSIS. Other inter-domain signalling issues such as TE, BB signaling, policy should be out of NSIS scope.

Hemant 

-----Original Message-----
From: ext Chen, Weijing [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 5:54 PM
To: 'Freytsis, Ilya'; 'Paulo Mendes'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [NSIS] RE: Independence of signalling and data path

                   |-----|   |----|   |-----|  

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2002 4:26 PM
To: 'Paulo Mendes'; Freytsis, Ilya
Cc: [email-masked]'; [email-masked]'
Subject: RE: [NSIS] RE: Independence of signalling and data path

Ilya

-----Original Message-----
From: Paulo Mendes [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 5:14 PM
To: Freytsis, Ilya
Cc: [email-masked]'; [email-masked]'
Subject: Re: [NSIS] RE: Independence of signalling and data path

Hello

Cheers
Paulo

---

From: "Chen, Weijing" <[email-masked]>
Date: Tue, 29 Jan 2002 17:13:44 -0600

You are right, Hemant.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2002 5:11 PM
To: Chen, Weijing
Cc: [email-masked]
Subject: RE: [NSIS] RE: Independence of signalling and data path

Hi:

IMHO, an important point to be stressed when talking inter-domain is that
only "host-specific" interdomain signalling (of course, if required) needs
to be covered by NSIS. Other inter-domain signalling issues such as TE, BB
signaling, policy should be out of NSIS scope.

Hemant 

-----Original Message-----
From: ext Chen, Weijing [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 5:54 PM
To: 'Freytsis, Ilya'; 'Paulo Mendes'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [NSIS] RE: Independence of signalling and data path

                   |-----|   |----|   |-----|  

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2002 4:26 PM
To: 'Paulo Mendes'; Freytsis, Ilya
Cc: [email-masked]'; [email-masked]'
Subject: RE: [NSIS] RE: Independence of signalling and data path

Ilya

-----Original Message-----
From: Paulo Mendes [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 5:14 PM
To: Freytsis, Ilya
Cc: [email-masked]'; [email-masked]'
Subject: Re: [NSIS] RE: Independence of signalling and data path

Hello

Cheers
Paulo

---

From: [email-masked]
Date: Wed, 30 Jan 2002 09:36:23 +0200

Hello Ilya,

> signaling used between those routers follows the same path as 
> data. What happens within the router is not a NSIS business.

I think that is a good analogy.  

John

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 30 Jan 2002 08:59:13 +0100

Hello Ilya

> It looks to me that this discussion got very heated because 
> it is at the very border between general QoS signaling and
> specific QoS technology in use (by the domain). The fact
> that you mentioned such terms as "Controller" and "BB" 
> indicates to me that you have a particular technology in 
> mind that based on this kind of entities. 

Sorry, I don't think that this is a question of technology, this is a question of architecture. As both solutions, centralized reservation control and decentralized reservation control, have their merits I wouldn't want to restrict standardisation on one. The generic NSIS features should be supported by both. Interworking then becomes an issue. If we call the one attempt "BB" and the other "Router", the following Interworkings apply:
BB - BB
Router - Router
BB - Router
Only the third one requires some more work. If NSIS succeeds in a generic signalling specification, such an interworking shouldn't be difficult.

Regards, Rüdiger

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Wed, 30 Jan 2002 10:07:54 -0500

Rüdiger,

I think there is a big difference between idea of "router" and "BB". Router
is one of the most generic ideas in the IP world while "BB" can be much more
tightly coupled with the bandwidth management technology in use. For that
reason I believe it would be much easier to standardize router-router
interworkings and leave router-BB (within the same domain) and BB-BB
(inter-domain) in the realm of specific technology. On the other hands if
we'll be able to find a common ground between different technologies for the
BB-BB interface I definitely would not object to include it into NSIS.

Regards,
Ilya  

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: Wednesday, January 30, 2002 2:59 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] RE: Independence of signalling and data path 

Hello Ilya

> mind that based on this kind of entities.

Sorry, I don't think that this is a question of technology, this is a
question of architecture. As both solutions, centralized reservation control
and decentralized reservation control, have their merits I wouldn't want to
restrict standardisation on one. The generic NSIS features should be
supported by both. Interworking then becomes an issue. If we call the one
attempt "BB" and the other "Router", the following Interworkings apply:
BB - BB
Router - Router
BB - Router
Only the third one requires some more work. If NSIS succeeds in a generic
signalling specification, such an interworking shouldn't be difficult.

Regards, Rüdiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 31 Jan 2002 09:16:24 +0100

Ilya,

Internet2's Simple Inter Domain Bandwidth Broker Signaling specification is 80% complete and I know of at least two research labs implementing it. As far as I know, Fred Baker of Cisco recommended to forward this work to IETF. I don't understand where you see a technological challenge.

To prevent the NSIS participants from getting me wrong: I don't and won't try to throw Internet2's specification on NSIS. I think it's another good input for discussion and lessons learned there may help to make NSIS a success. This statement applies independant of the architecture an NSIS protocol will work with.

Those who are interested in Internet2's results, check
http://qbone.internet2.edu/bb/index.shtml
You'll find an architecture, encodings and some state diagrams. However the work is not complete and some required improvements are easily visible (like address encoding). To the best of my knowledge, Internet2 will not complete the work (it has been a volunteer effort and the volunteers were running out of time).   

Regards, Rüdiger

> Rüdiger,
> 
> I think there is a big difference between idea of "router" 
> and "BB". Router is one of the most generic ideas in the
> IP world while "BB" can be much more tightly coupled
> with the bandwidth management technology in use. For that
> (inter-domain) in the realm of specific technology. On the 
> other hands if we'll be able to find a common ground between different 
> technologies for the BB-BB interface I definitely would not object
> to include it into NSIS.
> 
> Regards,
> Ilya  
>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 31 Jan 2002 10:03:28 +0100

Hi Ilya

Regarding your following statement:

[IF]>> In other words I am suggesting the following global analogy: 
[IF]>> If you view the domain with a QoS technology as a 
[IF]>> virtual router than NSIS
[IF]>> signaling used between those routers follows the same 
[IF]>> path as data. What
[IF]>> happens within the router is not a NSIS business.

I partially agree! 

I believe that the NSIS protocol when needed,
should be capable of operating within a QoS domain
(that is a QoS domain administrated by a provider).
However, if the QoS functionality is provided by a Bandwidth Broker
or the domain is overprovisioned then the signaling path and user data path
can be independent (not the same). Of course this can be chosen by the 
provider!

But when a provider would want to use the NSIS protocol within the 
domain for QoS support, then it should be possible to set (activate) 
the NSIS protocol such that the signaling path and user data path use the 
same path.

I agree with the rest of your statement!

Best Regards,
Georgios

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: dinsdag 29 januari 2002 18:45
To: [email-masked]'
Cc: [email-masked]'
Subject: [NSIS] RE: Independence of signalling and data path 

Marcus, 

Ilya Freytsis

Georgios,

see inline

No, I do not agree.

Marcus

---

From: [email-masked]
Date: Thu, 31 Jan 2002 12:17:25 -0000

I think that we are all moving to is a generic NSIS protocol that is
applicable to the Host-Edge and the Edge-Edge interfaces. The use of it
within a domain (hop-hop) must always be the decision of the domain
operator. This is because:
1. An operator of a domain will make their own decisions regarding protocol
selection
2. domain operators need a generalised QoS protocol for interconnect
3. Some approaches for QoS (at least the bandwidth part) do not require any
signalling (e.g. overprovision).

In case 3, it seems to me this is a specialised case of Edge-Edge. The two
edges in this case are within a single domain or technology type, and the
NSIS signalling protocol must traverse it in order to reach the next domain
or QoS technology type.

Dick

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: 31 January 2002 09:03
To: 'Freytsis, Ilya'; [email-masked]'
Cc: [email-masked]'
Subject: RE: [NSIS] RE: Independence of signalling and data path 

Hi Ilya

I partially agree! 

Best Regards,
Georgios

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: dinsdag 29 januari 2002 18:45
To: [email-masked]'
Cc: [email-masked]'
Subject: [NSIS] RE: Independence of signalling and data path 

Marcus, 

Ilya Freytsis

Georgios,

see inline

No, I do not agree.

Marcus

---

From: [email-masked]
Date: Thu, 31 Jan 2002 14:21:47 +0200

Hi Dick,

> applicable to the Host-Edge and the Edge-Edge interfaces. The 
> use of it within a domain (hop-hop) must always be the decision of the 
> domain operator. 

I agree.  I think in the Framework document, we should fully
describe this.

> This is because:
> 1. An operator of a domain will make their own decisions 
> regarding protocol selection
> 3. Some approaches for QoS (at least the bandwidth part) do 
> not require any signalling (e.g. overprovision).

Additionally, I would believe that besides over-provisioning,
some service providers might prefer to use 'contractual signaling'
(having a signed contract for a fixed pipe) for transit
networks.

> In case 3, it seems to me this is a specialised case of 
> Edge-Edge. The two edges in this case are within a single domain 
> or technology type, and the NSIS signalling protocol must traverse 
> it in order to reach the next domain or QoS technology type.

Agreed.

John

---

From: [email-masked]
Date: Thu, 31 Jan 2002 14:52:28 +0200

Hi Ilya,

> technologies for the BB-BB interface I definitely would not object

Perhaps we should use a more generic term, such as proxy.
This proxy could be light-weight & reside at an edge router, 
or at a bandwidth broker.  I think that we should stick
to a more generic term, because when discussing Bandwidth 
broakers, we come very close to actual reservation mechanisms.

John

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 31 Jan 2002 11:10:09 -0500

Dick:

  Sounds reasonable. The only small addition, which is probably obvious, is
to be careful about the need to distinguish between host-to-edge and
edge-to-edge
interactions. At one level of abstraction, a client-server model is
applicable,
where the client is either a host or a network/bandwidth broker. Any
variations in
the solution that distinguishes host-to-edge from edge-to-edge thus needs to
be
justified against the added complexity. And, just to pursue that thought,
given the
activities going on in signalling compression, bandwidth efficiency across
the
host to network link should not be overly emphasized.

 I realize that this abstract will probably break down when we get to the
point
of looking at the specifics of each case. However, I am wondering if it is
possible
to construct the requirements for the more general client-server model? This
could
cut the number of requirements nearly in half, and the associated debate by
an
order of magnitude ;^).

 Just a thought.

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: January 31, 2002 07:17
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> use of it
> Edge-Edge. The two
> it is at the
> data. What
> (was RE: [NSIS]