[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spc connections

Woops, I guess I should have read your message before sending my previous mail.

Kireeti,
As I mentioned in that mail, I agree that explicitly documenting egress label control seems like the thing to do now. I suggest that this be done in a standalone document as it has application outside of overlay/UNI. The text below is overly specific.

Lou

At 10:31 PM 11/14/2003, Kireeti Kompella wrote:

Hi Lyndon,

On Wed, 12 Nov 2003, Ong, Lyndon wrote:

> 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.

Should probably have added at the end 'if any'.

What wasn't clearly specified is the cross-connections. Here's a picture:

                           U1/D1              explicit labels
                    .... Y ----- Z -----      associated with Z: U2/D2

Z is the egress; Y the egress's upstream node.  Y advertises U1 to Z
in its Path, Z advertises D1 to Y in its Resv.  Z also notes that the
explicit labels associated with Z in the ERO are U2 (upstream) and D2.

Z cross-connects D1 with D2; and also cross-connects U2 with U1.  It
would have been nice to be more, um, explicit about this, but we can
fix this in the overlay doc.

> Explicit Label Control seems like it would help you control the label assignment
> within the signaled portion of a connection.

Not having a Path message beyond the egress core-node only means
that the signaling stops at the core-node.  However, the correct
cross-connections can still be made.

Suggested change of text for the Overlay draft:

REPLACE:

3.3. Explicit Label Control

   In order to support explicit label control and full identification of
   the egress link an ingress edge-node may include an ERO that consists
   of only the last hop.  This is signaled by setting the first
   subobject of the ERO to the node-ID of the egress core-node with the
   L-bit set.  Following this subobject are all other subobjects
   necessary to identify the link and labels as they would normally
   appear.

WITH:

3.3. Explicit Label Control

   In order to support explicit label control and full identification of
   the egress link, an ingress edge-node may include an ERO whose last
   group of subobjects are set as follows:
      subobject identifying the egress core-node (CN3);
      subobject identifying the link I downstream of CN3 (if needed);
      subobject identifying the label(s) L1 and L2 on link I (if needed)

                                     U1/D1      I:U2/D2
        EN1 ------- CN1 ------- CN2 ------- CN3 ------- EN2

   These may be the only subobjects in the ERO, or there may be others
   preceding them.

   The subobject identifying the egress core-node MAY have the L-bit
   set.  If so, the egress core-node SHOULD NOT send a PathErr, despite
   section 5.1.1 of RFC 3473.

   On receiving such an ERO, the egress core-node CN3 MUST cross-connect
   the downstream label D1 that it sends to its upstream node CN2 with
   the downstream explicit label D2 associated with CN3 in the ERO.  If
   the LSP is bidirectional, CN3 MUST also cross-connect the upstream
   label U2 in the ERO with the upstream label U1 it received from CN2.

   If either of these cross-connections fails, the egress core-node
   SHOULD send a PathErr with <error code>.

END

Kireeti.
-------