Subject: Re: [NSIS] question for clarification

From: "jkchoi" <[email-masked]>
Date: Mon, 5 Aug 2002 01:43:26 +0900

I just read this mail. It is me to raise a question for bi-directional QoS signaling at nsis WG.

For the further development of "A Framework for Bi-Directional QoS Signaling" presented at Yokohama meeting,
it needs to check the existing activities at mpls WG and ccamp WG to their signaling protocols 
(If time is available, check the signaling protocols developed by ITU-T SG13 and ISO/OSI etc. even though it is not for IP network.
You can find some helpful mechanism to use for IP network.)

It notes that

 - uni-directional signaling on LDP/CR-LDP and RSVP/RSVP-TE for MPLS network
 - on-going for bi-directional signaling on RSVP-TE and CR-LDP extension for GMPLS network.

It also notes that most of the ATM network and most of data network use the bi-directional signaling in general.

The author of draft-shahrier-nsis-framework-00.txt may first hear some backgrounds why the mpls WG choose uni-directional signaling.
It was taken with some considerations of physical media type, end user applications, network provider operation and maintenance, and system implementation, etc. 
In addition, routing algorithm and forwarding logic of IP router are another factors for decision.
In order to make a decision for bi-directional signaling at nsis WG, it may be needed to check the related technical issues including end user requirements, network operator requirements and system designer requirements.
It may help to clarify the needs and the work scopes of that draft. Specifically, it may need to find target signaling objectives according to layered concept, service provisioning rule, gegographical view, network dimensioning and physical coverage, etc.

In my personal views (since I am much oriented on telco- viewpoints), I don't clearly understand what is the real objectives of this draft ?
What is the target application ? Is that only for a specific end appllication, otherwise is it generally both for end user and network provider ?
I think that the author may find some critical problems on the existing activities of bi-directional signaling at other group or other body.
Why new bi-directional signaling protocol is needed ?
It may be reasonable to wait until the nsis WG finish the requirements even though I don't follow what is going on in detail yet.

In general, different and individual signaling protocols are needed when end applications and intermediate network elements are different on operational rule, service provisioning, and control mechanism including resource reservation, etc.
If a number of signaling requirements merge into one set of signaling protocol, some trade-offs among benefits, cost, and performance must be analyzed. It notes that the trade-off analyses are not just focusing on technical matters.

Jun Kyun Choi

----- Original Message ----- 
From: "Marcus Brunner" <[email-masked]>
To: "Shahrier, Sharif M." <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 30, 2002 4:50 PM
Subject: RE: [NSIS] question for clarification

> Whach the ccamp WG
> MArcus
> 
> --On Montag, 29. Juli 2002 14:49 -0400 "Shahrier, Sharif M." 
> <[email-masked]> wrote:
> 
> > Marcus,
> >
> > Thanks for the information. Would you have the link to this draft
> > that you can send to us? Thanks.
> >
> > Sharif.
> >
> >
> >  -----Original Message-----
> > From: Marcus Brunner [mailto:[email-masked]]
> > Sent: Thursday, July 25, 2002 6:36 AM
> > To: Shahrier, Sharif M.
> > Cc: [email-masked]'
> > Subject: Re: [NSIS] question for clarification
> >
> > Sharif,
> >
> > RSVP-TE with GMPLS extension is a signaling protocol for setting up GMPLS
> > pathes, which might be optical or what ever. There one of the extension
> > is  that they allow for bi-directional path setup.
> >
> > Marcus
> >
> > --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M."
> > <[email-masked]> wrote:
> >
> >> Following my presentation of the framework draft at Yokohama, a person
> >> had asked me whether our approach was the same as the "bi-directional
> >> GMPLS" that the MPLS WG had worked on.
> >>
> >> I am not sure what this is, and would appreciate if that person can
> >> provide us with more information.
> >> Thanks.
> >>
> >> Sharif.
> >>

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

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 05 Aug 2002 10:59:49 +0200

Concerning bi-directional,

In the requirements draft we currently have
--------------
5.7.4 Uni / bi-directional reservation

Both unidirectional as well as bi-direction reservations must be possible. 
With bi-directional reservations we mean here reservations having the same 
end-points. But the path in the two directions does not need to be the same.

The goal of a bi-directional reservation is mainly an optimization in terms 
of setup delay. There is no requirements on constrains such as use the same 
data path etc.
-------------

It is important to note that we explicity mention that bi-directional is 
meant to have only the same end-points, but does not need to follow the 
same path. This is follwing the Internet Routing ARchitecture.

Any constraint to force bi-directional reservations on the same path are 
very complex and not workable in many cases.

Marcus

--On Montag, 5. August 2002 01:43 +0900 jkchoi <[email-masked]> wrote:

> For the further development of "A Framework for Bi-Directional QoS
> Signaling" presented at Yokohama meeting, it needs to check the existing
> activities at mpls WG and ccamp WG to their signaling protocols  (If time
> is available, check the signaling protocols developed by ITU-T SG13 and
> ISO/OSI etc. even though it is not for IP network. You can find some
> helpful mechanism to use for IP network.)
>
> It notes that
>
>  - uni-directional signaling on LDP/CR-LDP and RSVP/RSVP-TE for MPLS
> network  - on-going for bi-directional signaling on RSVP-TE and CR-LDP
> extension for GMPLS network.
>
> The author of draft-shahrier-nsis-framework-00.txt may first hear some
> backgrounds why the mpls WG choose uni-directional signaling. It was
> taken with some considerations of physical media type, end user
> applications, network provider operation and maintenance, and system
> implementation, etc.  In addition, routing algorithm and forwarding logic
> of IP router are another factors for decision. In order to make a
> decision for bi-directional signaling at nsis WG, it may be needed to
> check the related technical issues including end user requirements,
> network operator requirements and system designer requirements. It may
> help to clarify the needs and the work scopes of that draft.
> Specifically, it may need to find target signaling objectives according
> to layered concept, service provisioning rule, gegographical view,
> network dimensioning and physical coverage, etc.
>
> In my personal views (since I am much oriented on telco- viewpoints), I
> don't clearly understand what is the real objectives of this draft ? What
> is the target application ? Is that only for a specific end appllication,
> otherwise is it generally both for end user and network provider ? I
> think that the author may find some critical problems on the existing
> activities of bi-directional signaling at other group or other body. Why
> new bi-directional signaling protocol is needed ?
> It may be reasonable to wait until the nsis WG finish the requirements
> even though I don't follow what is going on in detail yet.
>
> In general, different and individual signaling protocols are needed when
> end applications and intermediate network elements are different on
> operational rule, service provisioning, and control mechanism including
> resource reservation, etc. If a number of signaling requirements merge
> into one set of signaling protocol, some trade-offs among benefits, cost,
> and performance must be analyzed. It notes that the trade-off analyses
> are not just focusing on technical matters.
>
> Jun Kyun Choi
>
>> > RSVP-TE with GMPLS extension is a signaling protocol for setting up
>> > GMPLS pathes, which might be optical or what ever. There one of the
>> > extension is  that they allow for bi-directional path setup.
>> >
>> > Marcus
>> >

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus

---

From: Dan Grossman <[email-masked]>
Date: Mon, 05 Aug 2002 11:59:20 -0400

PacketCable http://www.packetcable.com/specs/PKT-SP-DQOS-I03-020116.pdf has also
specified RSVP extensions for bi-directional reservations, in the context of IP
telephony over cable.  They're taking advantage of some unique topological
limitations that constrain flows in opposite directions to follow the same
path.   I don't think you want to preclude this case any more than you want to
require that flows always be constrained to follow the same path (or, actually,
reverse paths).   Questions:
  should we  do anything special in the signalling protocol to force or prefer
the same path?
  would it be desirable to discover those kinds of topological constraints and
take advantage of them in the signalling protocol where they exist?
  would  a style of bidirectional reservation that takes advantage of reverse
paths would be so much simpler than one that assumes non-reverse paths that it's
worth being a special case in the signalling protocol?

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 06 Aug 2002 10:04:54 +0200

--On Montag, 5. August 2002 11:59 -0400 Dan Grossman <[email-masked]> 
wrote:

> Questions:
>   should we  do anything special in the signalling protocol to force or
> prefer the same path?

That is exactly what I don't want to do. If the protocol works 
bi-directional on the same path due to topological constraints this is 
fine. But finding the same path is IMHO a routing issue. I pretty much like 
the decoupling of routing and signaling.

>   would it be desirable to discover those kinds of topological
> constraints and take advantage of them in the signalling protocol where
> they exist?   would  a style of bidirectional reservation that takes
> advantage of reverse paths would be so much simpler than one that assumes
> non-reverse paths that it's worth being a special case in the signalling
> protocol?

I currently assume that it is simpler. The issue is that the protocol 
should NOT take into account topological issues at all.

Marcus

>> Both unidirectional as well as bi-direction reservations must be
>> possible. With bi-directional reservations we mean here reservations
>> having the same end-points. But the path in the two directions does not
>> need to be the same.
>>
>> The goal of a bi-directional reservation is mainly an optimization in
>> terms of setup delay. There is no requirements on constrains such as use
>> the same data path etc.
>> -------------
>>
>> > Signaling" presented at Yokohama meeting, it needs to check the
>> > existing activities at mpls WG and ccamp WG to their signaling
>> > protocols  (If time is available, check the signaling protocols
>> > developed by ITU-T SG13 and ISO/OSI etc. even though it is not for IP
>> > network. You can find some helpful mechanism to use for IP network.)
>> >
>> > It notes that
>> >
>> > implementation, etc.  In addition, routing algorithm and forwarding
>> > logic of IP router are another factors for decision. In order to make a
>> > don't clearly understand what is the real objectives of this draft ?
>> > What is the target application ? Is that only for a specific end
>> > appllication, otherwise is it generally both for end user and network
>> > provider ? I think that the author may find some critical problems on
>> > the existing activities of bi-directional signaling at other group or
>> > other body. Why new bi-directional signaling protocol is needed ?
>> > In general, different and individual signaling protocols are needed
>> > when end applications and intermediate network elements are different
>> > on operational rule, service provisioning, and control mechanism
>> > including resource reservation, etc. If a number of signaling
>> > requirements merge into one set of signaling protocol, some trade-offs
>> > among benefits, cost, and performance must be analyzed. It notes that
>> > the trade-off analyses are not just focusing on technical matters.
>> >
>> > Jun Kyun Choi
>> >
>> >> >> Following my presentation of the framework draft at Yokohama, a
>> >> >> person had asked me whether our approach was the same as the
>> >> >> "bi-directional GMPLS" that the MPLS WG had worked on.
>> >> >>