[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [전체회신] Re: [ AuA¼E¸½A ] spc conn
hi, as said in the following mail
<http://psg.com/lists/ccamp/ccamp.2003/msg00987.html>
the point you mention here below
"[...] the destination egress network node could idntify itself to be the last network node and not to invoke connection establishment over UNI interface."
has been addressed, however it has not been taken into
account when info rfc3474 had been released
hope this helps,
- dimitri.
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C3AAC2.7A757040
> Content-Type: text/plain;
> charset="euc-kr"
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the
> definition of SPC_Label.
> The following description shows the definition of the SPC_Label.
>
> "This attribute represents the SNP used at the destination =
> network-to-user
> connection. The SPC SNP ID is locally unique to the destination end and
> provided to the control plane by an external agent (e.g., the =
> management
> system that initiated the SPC connection request). Note that in the =
> case of
> the SPC connection, both source and destination user-to-network =
> connections
> are provisioned. As such, when setting up a network switched connection =
> to
> support the SPC service, the destination SNP associated with the
> provisioned connection needs to be specified to allow the control plane =
> to
> connect the switched connection to the destination portion of the
> provisioned connection."
>
> After reading this clause, I bacame to understand the reason that
> "Generalized_UNI" object included the SPC_Label subobject. Like the
> definition above, SPC_Label shows the provisioned connection label over =
> UNI
> portion, not NNI portion.
> As such, I think it is right for "Generalized_UNI" object to include =
> the
> SPC_Label subobject. In addition, by using this subobject and other
> information(maybe, ERO etc), the destination egress network node could
> idntify itself to be the last network node and not to invoke connection
> establishment over UNI interface.
>
> I hope this email conclude the discussion of SPC connections.
> And, I'd like to know which WG rfc3476 is an output from because I =
> think it
> is not a output of ccamp WG.
>
> Thanks,
> Young
>
>
>
>
> =BF=F8=BA=BB =B3=BB=BF=EB:
>
> =BA=B8=B3=BD=BB=E7=B6=F7: Jonathan Sadler[jonathan.sadler@tellabs.com]
> =B9=DE=B4=C2=BB=E7=B6=F7: yhwkim@etri.re.kr
> =C2=FC=C1=B6:adrian@olddog.co.uk; LyOng@ciena.com; kireeti@juniper.net;
> ccamp@ops.ietf.org
> =C1=A6=B8=F1: Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections
> =B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/14 =B1=DD 00:31
>
> 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=3D4,
> Sub-type=3D2)=20
> subobject seems to be included in GENERALIZED_UNI object.=20
> 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.=20
> >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,=20
> Young
> ¿øº» ³»¿ë:
> º¸³½»ç¶÷: Adrian
> Farrel[adrian@olddog.co.uk]=20
> ¹Þ´Â»ç¶÷: Ong, Lyndon=20
> ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org=20
> Á¦¸ñ: spc connections=20
> ¹ÞÀº³¯Â¥: 2003/11/13
> ¸ñ 06:57=20
> =20
> Lyndon,=20
> Thank you for raising this. There is certainly a lack of clarity in =
> 3473 in
> this regard,=20
> which is perhaps unfortunate.=20
> In the earlier versions of the GMPLS work, this was made very explicit
> (sic) because=20
> egress label control was invented before it was generalized to explicit
> label.=20
> There is some reference to this in RFC3471 (of course, the function was
> originally=20
> independent of signaling protocol), but no explicit procedures.=20
> This descriptive deficiency has been addressed in draft-ccamp-gmpls-
> overlay. There is no=20
> change in protocol to enable this function, merely a description of how =
> it
> all works.=20
> Hope this helps.=20
> Cheers,=20
> Adrian=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Hi Adrian,=20
> A couple of times now it's been suggested that Explicit Label Control =
> is a
> way to=20
> do SPC connections instead of the SPC_Label sub-object. I'm wondering =
> if=20
> people have a different model of SPC connections in mind. The =
> procedures
> in=20
> RFC 3473 for Explicit Label Control are as follows:=20
> [when a label sub-object is present] If the U-bit of the=20
> subobject being examined is clear (0), then value of the label is=20
> copied into a new Label_Set object. This Label_Set object MUST be=20
> included on the corresponding outgoing Path message.=20
> If the U-bit of the subobject being examined is set (1), then value=20
> of the label is label to be used for upstream traffic associated =
> with=20
> the bidirectional LSP.=20
> Neither of these would seem to help you for SPC, since there is no =
> outgoing
> PATH=20
> message at the network endpoint, the endpoint call control is handled =
> by=20
> the management system and not using a UNI or overlay interface (at =
> least=20
> as defined in G.8080).=20
> Explicit Label Control seems like it would help you control the label
> assignment=20
> within the signaled portion of a connection.
> Cheers,=20
> Lyndon
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The information contained in this message may be privileged=20
> and confidential and protected from disclosure. If the=20
> reader of this message is not the intended recipient, or an=20
> employee or agent responsible for delivering this message to=20
> the intended recipient, you are hereby notified that any=20
> reproduction, dissemination or distribution of this=20
> communication is strictly prohibited. If you have received=20
> this communication in error, please notify us immediately by=20
> replying to the message and deleting it from your computer.
>
> Thank you.
> Tellabs
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> ------_=_NextPart_001_01C3AAC2.7A757040
> Content-Type: text/html;
> charset="euc-kr"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Deuc-kr">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2653.12">
> <TITLE>[=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc =
> connections</TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=3D2>Hi,</FONT>
> </P>
>
> <P><FONT SIZE=3D2>I reviewed OIF E-NNI 1.0 document(oif2003.179.00) =
> that includes the definition of SPC_Label.</FONT>
> <BR><FONT SIZE=3D2>The following description shows the definition of =
> the SPC_Label.</FONT>
> </P>
>
> <P><FONT SIZE=3D2>"This attribute represents the SNP used at the =
> destination network-to-user connection. The SPC SNP ID is locally =
> unique to the destination end and provided to the control plane by an =
> external agent (e.g., the management system that initiated the SPC =
> connection request). Note that in the case of the SPC connection, both =
> source and destination user-to-network connections are provisioned. As =
> such, when setting up a network switched connection to support the SPC =
> service, the destination SNP associated with the provisioned connection =
> needs to be specified to allow the control plane to connect the =
> switched connection to the destination portion of the provisioned =
> connection."</FONT></P>
>
> <P><FONT SIZE=3D2>After reading this clause, I bacame to understand the =
> reason that "Generalized_UNI" object included the SPC_Label =
> subobject. Like the definition above, SPC_Label shows the provisioned =
> connection label over UNI portion, not NNI portion.</FONT></P>
>
> <P><FONT SIZE=3D2>As such, I think it is right for =
> "Generalized_UNI" object to include the SPC_Label =
> subobject. In addition, by using this subobject and other =
> information(maybe, ERO etc), the destination egress network node could =
> idntify itself to be the last network node and not to invoke connection =
> establishment over UNI interface.</FONT></P>
>
> <P><FONT SIZE=3D2>I hope this email conclude the discussion of SPC =
> connections.</FONT>
> <BR><FONT SIZE=3D2>And, I'd like to know which WG rfc3476 is an output =
> from because I think it is not a output of ccamp WG.</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Thanks,</FONT>
> <BR><FONT SIZE=3D2>Young</FONT>
> </P>
> <BR>
> <BR>
> <BR>
>
> <P><FONT SIZE=3D2>=BF=F8=BA=BB =B3=BB=BF=EB:</FONT>
> </P>
>
> <P><FONT SIZE=3D2>=BA=B8=B3=BD=BB=E7=B6=F7: Jonathan =
> Sadler[jonathan.sadler@tellabs.com]</FONT>
> <BR><FONT SIZE=3D2>=B9=DE=B4=C2=BB=E7=B6=F7: yhwkim@etri.re.kr</FONT>
> <BR><FONT SIZE=3D2>=C2=FC=C1=B6:adrian@olddog.co.uk; LyOng@ciena.com; =
> kireeti@juniper.net; ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>=C1=A6=B8=F1: Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc =
> connections</FONT>
> <BR><FONT SIZE=3D2>=B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/14 =B1=DD =
> 00:31</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Hi Young -</FONT>
> <BR><FONT SIZE=3D2>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)</FONT></P>
>
> <P><FONT SIZE=3D2>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.</FONT></P>
>
> <P><FONT SIZE=3D2>I hope this helps clarify SPC operations in =
> G.7713.2/RFC 3474.</FONT>
> <BR><FONT SIZE=3D2>Jonathan Sadler</FONT>
> <BR><FONT SIZE=3D2>yhwkim@etri.re.kr wrote:</FONT>
> <BR><FONT SIZE=3D2>Hi,</FONT>
> <BR><FONT SIZE=3D2>In my understanding, for the support of SPC =
> connection, SPC_LABEL (Type=3D4, Sub-type=3D2) </FONT>
> <BR><FONT SIZE=3D2>subobject seems to be included in GENERALIZED_UNI =
> object. </FONT>
> <BR><FONT SIZE=3D2>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>
>
> <P><FONT SIZE=3D2>As it is, GENERALIZED_UNI object describes =
> originating and terminating UNI aspects between client and network =
> nodes. </FONT>
> <BR><FONT SIZE=3D2>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>
>
> <P><FONT SIZE=3D2>What do you think of my opinion?</FONT>
> <BR><FONT SIZE=3D2>Thanks, </FONT>
> <BR><FONT SIZE=3D2>Young</FONT>
> <BR><FONT SIZE=3D2>&iquest;&oslash;&ordm;&raquo; =
> &sup3;&raquo;&iquest;&euml;:</FONT>
> <BR><FONT =
> SIZE=3D2>&ordm;&cedil;&sup3;&frac12;&raquo;&cced=
> il;&para;&divide;: Adrian Farrel[adrian@olddog.co.uk] </FONT>
> <BR><FONT =
> SIZE=3D2>&sup1;&THORN;&acute;&Acirc;&raquo;&cced=
> il;&para;&divide;: Ong, Lyndon </FONT>
> <BR><FONT SIZE=3D2>&Acirc;&uuml;&Aacute;&para;:'Kireeti =
> Kompella'; ccamp@ops.ietf.org </FONT>
> <BR><FONT SIZE=3D2>&Aacute;&brvbar;&cedil;&ntilde;: spc =
> connections </FONT>
> <BR><FONT =
> SIZE=3D2>&sup1;&THORN;&Agrave;&ordm;&sup3;&macr;=
> &Acirc;&yen;: 2003/11/13 &cedil;&ntilde; 06:57 </FONT>
> <BR><FONT SIZE=3D2> </FONT>
> <BR><FONT SIZE=3D2>Lyndon, </FONT>
> <BR><FONT SIZE=3D2>Thank you for raising this. There is certainly a =
> lack of clarity in 3473 in this regard, </FONT>
> <BR><FONT SIZE=3D2>which is perhaps unfortunate. </FONT>
> <BR><FONT SIZE=3D2>In the earlier versions of the GMPLS work, this was =
> made very explicit (sic) because </FONT>
> <BR><FONT SIZE=3D2>egress label control was invented before it was =
> generalized to explicit label. </FONT>
> <BR><FONT SIZE=3D2>There is some reference to this in RFC3471 (of =
> course, the function was originally </FONT>
> <BR><FONT SIZE=3D2>independent of signaling protocol), but no explicit =
> procedures. </FONT>
> <BR><FONT SIZE=3D2>This descriptive deficiency has been addressed in =
> draft-ccamp-gmpls-overlay. There is no </FONT>
> <BR><FONT SIZE=3D2>change in protocol to enable this function, merely a =
> description of how it all works. </FONT>
> <BR><FONT SIZE=3D2>Hope this helps. </FONT>
> <BR><FONT SIZE=3D2>Cheers, </FONT>
> <BR><FONT SIZE=3D2>Adrian </FONT>
> <BR><FONT =
> SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> </FONT>
> <BR><FONT SIZE=3D2>Hi Adrian, </FONT>
> <BR><FONT SIZE=3D2>A couple of times now it's been suggested that =
> Explicit Label Control is a way to </FONT>
> <BR><FONT SIZE=3D2>do SPC connections instead of the SPC_Label =
> sub-object. I'm wondering if </FONT>
> <BR><FONT SIZE=3D2>people have a different model of SPC connections in =
> mind. The procedures in </FONT>
> <BR><FONT SIZE=3D2>RFC 3473 for Explicit Label Control are as follows: =
> </FONT>
> <BR><FONT SIZE=3D2> [when a label sub-object is =
> present] If the U-bit of the </FONT>
> <BR><FONT SIZE=3D2> subobject being examined is clear (0), =
> then value of the label is </FONT>
> <BR><FONT SIZE=3D2> copied into a new Label_Set =
> object. This Label_Set object MUST be </FONT>
> <BR><FONT SIZE=3D2> included on the corresponding outgoing =
> Path message. </FONT>
> <BR><FONT SIZE=3D2> If the U-bit of the subobject being =
> examined is set (1), then value </FONT>
> <BR><FONT SIZE=3D2> of the label is label to be used for =
> upstream traffic associated with </FONT>
> <BR><FONT SIZE=3D2> the bidirectional LSP. </FONT>
> <BR><FONT SIZE=3D2>Neither of these would seem to help you for SPC, =
> since there is no outgoing PATH </FONT>
> <BR><FONT SIZE=3D2>message at the network endpoint, the endpoint call =
> control is handled by </FONT>
> <BR><FONT SIZE=3D2>the management system and not using a UNI or overlay =
> interface (at least </FONT>
> <BR><FONT SIZE=3D2>as defined in G.8080). </FONT>
> <BR><FONT SIZE=3D2>Explicit Label Control seems like it would help you =
> control the label assignment </FONT>
> <BR><FONT SIZE=3D2>within the signaled portion of a connection.</FONT>
> <BR><FONT SIZE=3D2>Cheers, </FONT>
> <BR><FONT SIZE=3D2>Lyndon</FONT>
> </P>
>
> <P><FONT =
> SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
> <BR><FONT SIZE=3D2>The information contained in this message may be =
> privileged </FONT>
> <BR><FONT SIZE=3D2>and confidential and protected from disclosure. If =
> the </FONT>
> <BR><FONT SIZE=3D2>reader of this message is not the intended =
> recipient, or an </FONT>
> <BR><FONT SIZE=3D2>employee or agent responsible for delivering this =
> message to </FONT>
> <BR><FONT SIZE=3D2>the intended recipient, you are hereby notified that =
> any </FONT>
> <BR><FONT SIZE=3D2>reproduction, dissemination or distribution of this =
> </FONT>
> <BR><FONT SIZE=3D2>communication is strictly prohibited. If you have =
> received </FONT>
> <BR><FONT SIZE=3D2>this communication in error, please notify us =
> immediately by </FONT>
> <BR><FONT SIZE=3D2>replying to the message and deleting it from your =
> computer.</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Thank you.</FONT>
> <BR><FONT SIZE=3D2>Tellabs</FONT>
> <BR><FONT =
> SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C3AAC2.7A757040--
>
>