[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ Àüüȸ½Å ] spc connections
jonathan,
clarification inline...
> Dimitri -
>
> Response inline...
>
> Jonathan Sadler
>
> Dimitri Papadimitriou wrote:
>
> > 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.8080 requires that a call be established for SPCs (soft permanent connections) as well as SC (switched connections). G.7713 and G.7713.2 follow this requirement.
i'll clarify, i was referring to supporting simply being
able to set up a spc without a call and the capability to
support a call with no connections for which one or more
spc and/or sc's are associated subsequently
> > - G.7713.2/RFC 3474 can not support inter-as *te* ?
>
> I'm not certain how to parse your question -- could you please clarify?
adrian's mail clarifies this,
thanks,
- dimitri.
> > 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--
> > >
> > >
> > >
>
>
> -----------------------------------------
> ============================================================
> 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
> ============================================================
>
>