[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [????] spc connections
hi, your understanding is correct, the SPC_LABEL is included
in the GENERALIZED_UNI object
also your suggestion is in-line with:
<http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt>
thanks,
- 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_01C3A979.9A4B50F0
> Content-Type: text/plain;
> charset="KS_C_5601-1987"
> Content-Transfer-Encoding: quoted-printable
>
> Good analysis.
>
> -----Original Message-----
> From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr]
> Sent: Wednesday, November 12, 2003 3:48 PM
> To: adrian@olddog.co.uk; LyOng@ciena.com
> Cc: kireeti@juniper.net; ccamp@ops.ietf.org
> Subject: [????] spc connections
>
>
>
> Hi,=20
>
> 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?=20
>
> Thanks,=20
> Young=20
>
>
> =BF=F8=BA=BB =B3=BB=BF=EB:=20
>
> =BA=B8=B3=BD=BB=E7=B6=F7: Adrian Farrel[adrian@olddog.co.uk]=20
> =B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon=20
> =C2=FC=C1=B6:'Kireeti Kompella'; ccamp@ops.ietf.org=20
> =C1=A6=B8=F1: spc connections=20
> =B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/13 =B8=F1 06:57=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=20
>
> 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.=20
>
> Cheers,=20
> Lyndon=20
>
>
> ------_=_NextPart_001_01C3A979.9A4B50F0
> Content-Type: text/html;
> charset="KS_C_5601-1987"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3DKS_C_5601-1987">
> <TITLE>[=C0=FC=C3=BC=C8=B8=BD=C5] spc connections</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV><SPAN class=3D079440400-13112003><FONT face=3DArial =
> color=3D#0000ff size=3D2>Good=20
> analysis.</FONT></SPAN></DIV>
> <BLOCKQUOTE dir=3Dltr=20
> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
> solid; MARGIN-RIGHT: 0px">
> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
> face=3DTahoma=20
> size=3D2>-----Original Message-----<BR><B>From:</B> yhwkim@etri.re.kr =
>
> [mailto:yhwkim@etri.re.kr]<BR><B>Sent:</B> Wednesday, November 12, =
> 2003 3:48=20
> PM<BR><B>To:</B> adrian@olddog.co.uk; LyOng@ciena.com<BR><B>Cc:</B>=20
> kireeti@juniper.net; ccamp@ops.ietf.org<BR><B>Subject:</B> [????] spc =
>
> connections<BR><BR></FONT></DIV>
> <P><FONT size=3D2>Hi,</FONT> </P>
> <P><FONT size=3D2>In my understanding, for the support of SPC =
> connection,=20
> SPC_LABEL (Type=3D4, Sub-type=3D2)</FONT> <BR><FONT =
> size=3D2>subobject seems to be=20
> included in GENERALIZED_UNI object.</FONT> <BR><FONT size=3D2>If my=20
> understanding is correct, I think there is a big ifference between =
> concept of=20
> SPC connection and GENERALIZED_UNI object. SPC connection is NNI =
> portion, not=20
> UNI.</FONT></P>
> <P><FONT size=3D2>As it is, GENERALIZED_UNI object describes =
> originating and=20
> terminating UNI aspects between client and network nodes.</FONT> =
> <BR><FONT=20
> size=3D2>From logical view-point, in addition, the difference between =
> switched=20
> 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=20
> in case of SPC the initiation is of network node (of course, =
> triggered by=20
> NMS). As a result, I think that GENERALIZED_UNI object and SPC =
> connection=20
> could not be indicated by using the object, called GENERALIZED_UNI =
> object=20
> because these are completely different by nature.</FONT></P>
> <P><FONT size=3D2>What do you think of my opinion?</FONT> </P>
> <P><FONT size=3D2>Thanks,</FONT> <BR><FONT size=3D2>Young</FONT> =
> </P><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: Adrian =
> Farrel[adrian@olddog.co.uk]</FONT> <BR><FONT=20
> size=3D2>=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon</FONT> <BR><FONT =
> size=3D2>=C2=FC=C1=B6:'Kireeti Kompella';=20
> ccamp@ops.ietf.org</FONT> <BR><FONT size=3D2>=C1=A6=B8=F1: spc =
> connections=20
> </FONT><BR><FONT size=3D2>=B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/13 =B8=F1 =
> 06:57</FONT> </P><BR><BR>
> <P><FONT size=3D2>Lyndon,</FONT> <BR><FONT size=3D2>Thank you for =
> raising this.=20
> There is certainly a lack of clarity in 3473 in this regard, =
> </FONT><BR><FONT=20
> size=3D2>which is perhaps unfortunate.</FONT> <BR><FONT size=3D2>In =
> the earlier=20
> 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=20
> generalized to explicit label.</FONT> <BR><FONT size=3D2>There is =
> some reference=20
> to this in RFC3471 (of course, the function was originally =
> </FONT><BR><FONT=20
> size=3D2>independent of signaling protocol), but no explicit =
> procedures.</FONT>=20
> <BR><FONT size=3D2>This descriptive deficiency has been addressed in=20
> draft-ccamp-gmpls-overlay. There is no </FONT><BR><FONT =
> size=3D2>change in=20
> protocol to enable this function, merely a description of how it all=20
> works.</FONT> <BR><FONT size=3D2>Hope this helps.</FONT> <BR><FONT=20
> size=3D2>Cheers, </FONT><BR><FONT size=3D2>Adrian </FONT><BR><FONT=20
> =
> size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> </FONT> </P>
> <P><FONT size=3D2>Hi Adrian,</FONT> <BR><FONT size=3D2>A couple of =
> times now it's=20
> been suggested that Explicit Label Control is a way to =
> </FONT><BR><FONT=20
> size=3D2>do SPC connections instead of the SPC_Label =
> sub-object. I'm=20
> wondering if </FONT><BR><FONT size=3D2>people have a different model =
> of SPC=20
> connections in mind. The procedures in </FONT><BR><FONT =
> size=3D2>RFC 3473=20
> for Explicit Label Control are as follows:</FONT> <BR><FONT=20
> size=3D2> [when a label sub-object is present] If =
> the U-bit of=20
> the </FONT><BR><FONT size=3D2> subobject being examined =
> is clear=20
> (0), then value of the label is </FONT><BR><FONT =
> size=3D2> copied=20
> into a new Label_Set object. This Label_Set object MUST be=20
> </FONT><BR><FONT size=3D2> included on the corresponding =
> outgoing=20
> Path message.</FONT> <BR><FONT size=3D2> If the U-bit of =
> the=20
> subobject being examined is set (1), then value </FONT><BR><FONT=20
> size=3D2> of the label is label to be used for upstream =
> traffic=20
> associated with </FONT><BR><FONT size=3D2> the =
> bidirectional=20
> LSP.</FONT> <BR><FONT size=3D2>Neither of these would seem to help =
> you for SPC,=20
> since there is no outgoing PATH </FONT><BR><FONT size=3D2>message at =
> the network=20
> endpoint, the endpoint call control is handled by </FONT><BR><FONT =
> size=3D2>the=20
> management system and not using a UNI or overlay interface (at least=20
> </FONT><BR><FONT size=3D2>as defined in G.8080).</FONT> <BR><FONT=20
> size=3D2>Explicit Label Control seems like it would help you control =
> the label=20
> assignment </FONT><BR><FONT size=3D2>within the signaled portion of a =
>
> connection.</FONT> </P>
> <P><FONT size=3D2>Cheers,</FONT> <BR><FONT size=3D2>Lyndon</FONT>=20
> </P></BLOCKQUOTE></BODY></HTML>
>
> ------_=_NextPart_001_01C3A979.9A4B50F0--
>
>