[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ Àüüȸ½Å ] spc connections
jonathan,
reading your mail, the following came to my mind:
- does it mean that G.7713.2/RFC 3474 requires to setup
a call when (or before) establishing an SPC ?
- G.7713.2/RFC 3474 can not support inter-as *te* ?
thanks,
- dimitri.
> --------------1FF6DF901322C8C0DC51EC75
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 8bit
>
> Hi Young -
>
> While the name of the "GENERALIZED_UNI" object seems to refer to the UNI
> reference point, the purpose of the object is to carry attributes of a
> call. G.8080 states that SPCs still use Network Call Controllers (NCCs)
> in the process of setting up the SPC. Consequently, a call exists even
> for SPCs. Therefore, carrying attributes of a call is independent of
> whether the call was requested across a UNI or from a management system
> (ie. an SPC). I agree that the name of the object is somewhat
> misleading, but it comes from the fact that G.7713.2 attempted to reuse
> existing RSVP extensions as much as possible. (The name of this Call
> object came from the OIF UNI 1.0 IA)
>
> The identification of the egress point in a carriers network to which an
> SPC is to be delivered is also a Call attribute, not a connection
> attribute -- it is independent of how a customer's service request is
> realized acrossed a service provider's network. However, the ERO is an
> attribute of a connection, not a call, and may not necessarily be passed
> over the E-NNI reference point. Consequently, the use of explicit label
> control in an ERO is not a possible way to handle SPCs that traverse an
> E-NNI. This is why the egress point identification appears in the call
> object in G.7713.2.
>
> I hope this helps clarify SPC operations in G.7713.2/RFC 3474.
>
> Jonathan Sadler
>
> yhwkim@etri.re.kr wrote:
>
> > Hi,
> >
> > In my understanding, for the support of SPC connection, SPC_LABEL
> > (Type=4, Sub-type=2)
> > subobject seems to be included in GENERALIZED_UNI object.
> > If my understanding is correct, I think there is a big ifference
> > between concept of SPC connection and GENERALIZED_UNI object. SPC
> > connection is NNI portion, not UNI.
> >
> > As it is, GENERALIZED_UNI object describes originating and terminating
> > UNI aspects between client and network nodes.
> > From logical view-point, in addition, the difference between switched
> > connection (SC) and soft permanent connection (SPC) is where call and
> > connection initiation is. In case of SC the initiation is of client
> > node, but in case of SPC the initiation is of network node (of course,
> > triggered by NMS). As a result, I think that GENERALIZED_UNI object
> > and SPC connection could not be indicated by using the object, called
> > GENERALIZED_UNI object because these are completely different by
> > nature.
> >
> > What do you think of my opinion?
> >
> > Thanks,
> > Young
> >
> > 원본 내용:
> >
> > 보낸사람: Adrian Farrel[adrian@olddog.co.uk]
> > 받는사람: Ong, Lyndon
> > 참조:'Kireeti Kompella'; ccamp@ops.ietf.org
> > 제목: spc connections
> > 받은날짜: 2003/11/13 목 06:57
> >
> >
> > Lyndon,
> > Thank you for raising this. There is certainly a lack of clarity in
> > 3473 in this regard,
> > which is perhaps unfortunate.
> > In the earlier versions of the GMPLS work, this was made very explicit
> > (sic) because
> > egress label control was invented before it was generalized to
> > explicit label.
> > There is some reference to this in RFC3471 (of course, the function
> > was originally
> > independent of signaling protocol), but no explicit procedures.
> > This descriptive deficiency has been addressed in
> > draft-ccamp-gmpls-overlay. There is no
> > change in protocol to enable this function, merely a description of
> > how it all works.
> > Hope this helps.
> > Cheers,
> > Adrian
> > =====================
> >
> > Hi Adrian,
> > A couple of times now it's been suggested that Explicit Label Control
> > is a way to
> > do SPC connections instead of the SPC_Label sub-object. I'm wondering
> > if
> > people have a different model of SPC connections in mind. The
> > procedures in
> > RFC 3473 for Explicit Label Control are as follows:
> > [when a label sub-object is present] If the U-bit of the
> > subobject being examined is clear (0), then value of the label is
> > copied into a new Label_Set object. This Label_Set object MUST be
> > included on the corresponding outgoing Path message.
> > If the U-bit of the subobject being examined is set (1), then value
> >
> > of the label is label to be used for upstream traffic associated
> > with
> > the bidirectional LSP.
> > Neither of these would seem to help you for SPC, since there is no
> > outgoing PATH
> > message at the network endpoint, the endpoint call control is handled
> > by
> > the management system and not using a UNI or overlay interface (at
> > least
> > as defined in G.8080).
> > Explicit Label Control seems like it would help you control the label
> > assignment
> > within the signaled portion of a connection.
> >
> > Cheers,
> > Lyndon
>
>
>
> -----------------------------------------
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
>
> Thank you.
> Tellabs
> ============================================================
> --------------1FF6DF901322C8C0DC51EC75
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> Hi Young -
> <p>While the name of the "GENERALIZED_UNI" object seems to refer to the
> UNI reference point, the purpose of the object is to carry attributes of
> a call. G.8080 states that SPCs still use Network Call Controllers
> (NCCs) in the process of setting up the SPC. Consequently, a call
> exists even for SPCs. Therefore, carrying attributes of a call is
> independent of whether the call was requested across a UNI or from a management
> system (ie. an SPC). I agree that the name of the object is somewhat misleading,
> but it comes from the fact that G.7713.2 attempted to reuse existing RSVP
> extensions as much as possible. (The name of this Call object came
> from the OIF UNI 1.0 IA)
> <p>The identification of the egress point in a carriers network to which
> an SPC is to be delivered is also a Call attribute, not a connection attribute
> -- it is independent of how a customer's service request is realized acrossed
> a service provider's network. However, the ERO is an attribute of a connection,
> not a call, and may not necessarily be passed over the E-NNI reference
> point. Consequently, the use of explicit label control in an ERO
> is not a possible way to handle SPCs that traverse an E-NNI. This
> is why the egress point identification appears in the call object in G.7713.2.
> <p>I hope this helps clarify SPC operations in G.7713.2/RFC 3474.
> <p>Jonathan Sadler
> <p>yhwkim@etri.re.kr wrote:
> <blockquote TYPE=CITE><font size=-1>Hi,</font>
> <p><font size=-1>In my understanding, for the support of SPC connection,
> SPC_LABEL (Type=4, Sub-type=2)</font>
> <br><font size=-1>subobject seems to be included in GENERALIZED_UNI object.</font>
> <br><font size=-1>If my understanding is correct, I think there is a big
> ifference between concept of SPC connection and GENERALIZED_UNI object.
> SPC connection is NNI portion, not UNI.</font>
> <p><font size=-1>As it is, GENERALIZED_UNI object describes originating
> and terminating UNI aspects between client and network nodes.</font>
> <br><font size=-1>From logical view-point, in addition, the difference
> between switched connection (SC) and soft permanent connection (SPC) is
> where call and connection initiation is. In case of SC the initiation is
> of client node, but in case of SPC the initiation is of network node (of
> course, triggered by NMS). As a result, I think that GENERALIZED_UNI object
> and SPC connection could not be indicated by using the object, called GENERALIZED_UNI
> object because these are completely different by nature.</font>
> <p><font size=-1>What do you think of my opinion?</font>
> <p><font size=-1>Thanks,</font>
> <br><font size=-1>Young</font>
> <p><font size=-1>¿øº» ³»¿ë:</font>
> <p><font size=-1>º¸³½»ç¶÷:
> Adrian Farrel[adrian@olddog.co.uk]</font>
> <br><font size=-1>¹Þ´Â»ç¶÷:
> Ong, Lyndon</font>
> <br><font size=-1>ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org</font>
> <br><font size=-1>Á¦¸ñ: spc connections</font>
> <br><font size=-1>¹ÞÀº³¯Â¥:
> 2003/11/13 ¸ñ 06:57</font>
> <br>
> <p><font size=-1>Lyndon,</font>
> <br><font size=-1>Thank you for raising this. There is certainly a lack
> of clarity in 3473 in this regard,</font>
> <br><font size=-1>which is perhaps unfortunate.</font>
> <br><font size=-1>In the earlier versions of the GMPLS work, this was made
> very explicit (sic) because</font>
> <br><font size=-1>egress label control was invented before it was generalized
> to explicit label.</font>
> <br><font size=-1>There is some reference to this in RFC3471 (of course,
> the function was originally</font>
> <br><font size=-1>independent of signaling protocol), but no explicit procedures.</font>
> <br><font size=-1>This descriptive deficiency has been addressed in draft-ccamp-gmpls-overlay.
> There is no</font>
> <br><font size=-1>change in protocol to enable this function, merely a
> description of how it all works.</font>
> <br><font size=-1>Hope this helps.</font>
> <br><font size=-1>Cheers,</font>
> <br><font size=-1>Adrian</font>
> <br><font size=-1>=====================</font>
> <p><font size=-1>Hi Adrian,</font>
> <br><font size=-1>A couple of times now it's been suggested that Explicit
> Label Control is a way to</font>
> <br><font size=-1>do SPC connections instead of the SPC_Label sub-object.
> I'm wondering if</font>
> <br><font size=-1>people have a different model of SPC connections in mind.
> The procedures in</font>
> <br><font size=-1>RFC 3473 for Explicit Label Control are as follows:</font>
> <br><font size=-1> [when a label sub-object is present]
> If the U-bit of the</font>
> <br><font size=-1> subobject being examined is clear (0), then
> value of the label is</font>
> <br><font size=-1> copied into a new Label_Set object.
> This Label_Set object MUST be</font>
> <br><font size=-1> included on the corresponding outgoing Path
> message.</font>
> <br><font size=-1> If the U-bit of the subobject being examined
> is set (1), then value</font>
> <br><font size=-1> of the label is label to be used for upstream
> traffic associated with</font>
> <br><font size=-1> the bidirectional LSP.</font>
> <br><font size=-1>Neither of these would seem to help you for SPC, since
> there is no outgoing PATH</font>
> <br><font size=-1>message at the network endpoint, the endpoint call control
> is handled by</font>
> <br><font size=-1>the management system and not using a UNI or overlay
> interface (at least</font>
> <br><font size=-1>as defined in G.8080).</font>
> <br><font size=-1>Explicit Label Control seems like it would help you control
> the label assignment</font>
> <br><font size=-1>within the signaled portion of a connection.</font>
> <p><font size=-1>Cheers,</font>
> <br><font size=-1>Lyndon</font></blockquote>
> </html>
>
> <HTML><BODY><P><hr size=1></P><P><STRONG>============================================================<br>The information contained in this message may be privileged <br>and confidential and protected from disclosure. If the <br>reader of this message is not the intended recipient, or an <br>employee or agent responsible for delivering this message to <br>the intended recipient, you are hereby notified that any <br>reproduction, dissemination or distribution of this <br>communication is strictly prohibited. If you have received <br>this communication in error, please notify us immediately by <br>replying to the message and deleting it from your computer.<br><br>Thank you.<br>Tellabs<br>============================================================</STRONG></P></BODY></HTML>
> --------------1FF6DF901322C8C0DC51EC75--
>
>
>