[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
   Internet Draft                                       Martin Machacek
   Document: draft-cai-vc-rsvp-te-00.txt                       Ting Cai
   Expires: August 2001                         Terabeam Networks, Inc.
                                                          February 2001


                Signaling Virtual Circuit Label Using RSVP-TE


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   This document proposes an extension to RSVP-TE to distribute VC
   labels required by L2 circuit over MPLS encapsulation proposed by
   Martini et. al.  The distribution of VC labels is piggybacked on
   signaling of LSP tunnels using two new RSVP objects.

Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   Conventions used in this document..................................2
   VC LABEL Object....................................................2
   VC LABEL REQUEST Object............................................4
   Processing Rules...................................................6
   Security Considerations............................................7
   Acknowledgements...................................................8
   References.........................................................9
   Author's Addresses.................................................9

   Cai           Internet Draft - Expires August 2001                1
            Signaling Virtual Circuit Label Using RSVP-TE February 2001

Introduction

   Martini et. al. proposed in [5] a method of encapsulating L2 PDUs in
   MPLS packets.  The method uses a stack of two labels: one specifying
   the LSP tunnel across the MPLS network and the other identifying the
   virtual circuit (VC) to which the L2 PDUs belong. Martini et. al.
   proposed a method for distributing VC labels using LDP in
   downstream-unsolicited mode in [2].

   We propose a simple extension to RSVP-TE [3] to signal VC labels
   using RSVP-TE in downstream-on-demand mode. The extension includes
   two new RSVP object classes, VC LABEL and VC LABEL REQUEST.  The
   data formats including their interpretations are taken from [2] with
   only minor modifications required by the RSVP object format. This
   should simplify implementations supporting both LDP and RSVP-TE.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [1].


VC LABEL Object

   The VC LABEL object MAY be used in RSVP RESV messages when replying
   to RSVP PATH messages with VC LABEL REQUEST object. The VC LABEL
   object SHOULD only be interpreted by the originator of the VC LABEL
   REQUEST object at the ingress of the tunnel.  Multiple VC LABEL
   objects MAY be present in one RESV message. If multiple VC LABEL
   objects with identical VC ID are present, the first object MUST be
   used while others MUST be ignored and notification to management
   SHOULD be generated.

   The VC LABEL Class number is 208 [Note] and currently only C-Type 1
   is defined. The VC LABEL class is optional from RSVP point of view.
   Based on rules in Section 3.10 of [4] all label switch routers (LSR)
   that do not support this class MUST ignore the object and pass it
   unchanged. LSRs supporting the VC Label Request class MUST also
   support VC Label class.

   The VC LABEL object has the following format:

   0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved   |C|         VC Type             |VC info Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Group ID                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        VC ID                                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Interface parameters                    |
     |                              "                                |

   Cai           Internet Draft - Expires August 2001                2
            Signaling Virtual Circuit Label Using RSVP-TE February 2001

     |                              "                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      VC LABEL                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved

        MUST be set to zero on transmission and ignored on receipt.

     VC TYPE

        A 15-bit quantity containing a value that represents the type
        of VC. Assigned values are:

                     VC Type  Description

                     0x0001   Frame Relay DLCI
                     0x0002   ATM AAL5 VCC transport
                     0x0003   ATM transparent cell transport
                     0x0004   Ethernet VLAN
                     0x0005   Ethernet
                     0x0006   HDLC ( Cisco )
                     0x0007   PPP
                     0x8008   CEM [8]
                     0x0009   ATM VCC cell transport
                     0x000A   ATM VPC cell transport
                     0x000B   MPLS

     Control word bit (C)

        The C bit is used to signal whether control word (as defined in
        [5]) will be used for the VC.

                     C bit = 1 control word present on this VC.
                     C bit = 0 no control word present on this VC.

     VC information length

        Length of the VC ID field and the interface parameters field in
        octets. If this value is 0, then it references all VCs using
        the specified group ID and there is no VC ID present, nor any
        interface parameters. The length must be multiple of 4.

     Group ID

        An arbitrary 32 bit value which represents a group of VCs that
        is used to augment the VC space. This value MUST be user
        configurable. The group ID is intended to be used as a port
        index, or a virtual tunnel index. To simplify configuration a
        particular VC ID at ingress could be part of the virtual tunnel
        for transport to the egress router. The Group ID can be used
        to send a wild card label withdrawals to remote LSRs upon
        physical port failure.


   Cai           Internet Draft - Expires August 2001                3
            Signaling Virtual Circuit Label Using RSVP-TE February 2001

     VC ID

        A non-zero 32-bit connection ID that together with the VC type,
        identifying VC for which label is being provided.

     Interface parameters

        A variable length field that is used to provide interface
        specific parameters of the egress interface of the VC. Format
        of this field is described in section 5.1 of [2]. Interface
        parameter field MAY be present even if no special parameters
        were requested in the corresponding LABEL REQUEST object. Total
        length of this field MUST be multiple of 4 and if necessary it
        MUST be padded with zeroes to the nearest 32-bit boundary.

     VC LABEL

        Generic MPLS label encoded right aligned in 4 octets. Note that
        ATM and Frame Relay labels cannot be used in this context.



VC LABEL REQUEST Object

   The VC LABEL REQUEST object MAY be used in RSVP PATH messages to
   request label mapping for a particular VC from the egress LSR. The
   VC LABEL REQUEST object SHOULD be interpreted only by the egress LSR
   whose router ID is the tunnel end point IP address in the Session
   object of the RSVP PATH message. Multiple VC LABEL REQUEST objects
   MAY be present in one PATH message. If multiple LABEL REQUEST
   objects with identical VC ID are present only the first one MUST be
   used while others MUST be ignored and notification to management
   SHOULD be generated.

   The VC LABEL REQUEST class number is 209 [Note] and currently only
   C-Type 1 is defined. The VC LABEL REQUEST object is optional from
   RSVP point of view.  Based on rules in Section 3.10 of [4] all LSRs
   that do not support this class MUST ignore it and pass it unchanged.
   LSRs supporting VC LABEL REQUEST class MUST also support VC LABEL
   class.

   The VC LABEL REQUEST object has following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved   |C|          VC TYPE              |VC Info Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Group ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           VC ID                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Interface Parameters                       |
     |                               "                               |

   Cai           Internet Draft - Expires August 2001                4
            Signaling Virtual Circuit Label Using RSVP-TE February 2001

     |                               "                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved

        MUST be zeroed on transmission and ignored on receipt.

     VC TYPE

        A 15-bit quantity containing a value which represents the type
        of VC. Assigned Values are:

                     VC Type  Description

                     0x0001   Frame Relay DLCI
                     0x0002   ATM AAL5 VCC transport
                     0x0003   ATM transparent cell transport
                     0x0004   Ethernet VLAN
                     0x0005   Ethernet
                     0x0006   HDLC ( Cisco )
                     0x0007   PPP
                     0x8008   CEM [8]
                     0x0009   ATM VCC cell transport
                     0x000A   ATM VPC cell transport
                     0x000B   MPLS

     Control word bit (C)

        The C bit is used to signal whether control word (as defined in
        [5]) will be used for the VC.

                     C bit = 1 control word present on this VC.
                     C bit = 0 no control word present on this VC.

     VC information length

        Length of the VC ID field and the interface parameters field in
        octets. If this value is 0, then it references all VCs using
        the specified group ID and there is no VC ID present, nor any
        interface parameters. The length must be multiple of 4.

     Group ID

        An arbitrary 32 bit value which represents a group of VCs that
        is used to augment the VC space. This value MUST be user
        configurable. The group ID is intended to be used as a port
        index, or a virtual tunnel index. To simplify configuration a
        particular VC ID at ingress could be part of the virtual tunnel
        for transport to the egress router. The Group ID is very useful
        to send a wild card label withdrawals to remote LSRs upon
        physical port failure.

     VC ID


   Cai           Internet Draft - Expires August 2001                5
            Signaling Virtual Circuit Label Using RSVP-TE February 2001

        A non-zero 32-bit connection ID that together with the VC type,
        identifying VC for which label is being provided.

     Interface parameters

        Variable length field is used to provide interface specific
        parameters of the ingress interface of the VC. Format of this
        field is described in section 5.1 of [2]. Interface parameter
        field MAY be present even if no special parameters were
        requested in corresponding LABEL REQUEST object. Total length
        of this field MUST be multiple of 4 and if necessary it MUST be
        padded with zeroes to the nearest 32-bit boundary.


Processing Rules

   Ingress

        To request VC label for a particular virtual circuit, the
        ingress of L2 tunnel places VC LABEL REQUEST objects with
        appropriate VC Type in RSVP PATH messages and sends them to the
        egress. VC Label Request objects SHOULD be placed immediately
        after LABEL REQUEST objects in the PATH message. The ingress
        node SHOULD set the C bit in the VC LABEL REQUEST object if it
        intends to use the control word in the encapsulation of L2
        PDUs. The ingress node MUST NOT send data over the L2 circuit
        if:

                - the egress node does not reply with VC LABEL object
                - the VC LABEL object has C bit set and the LSR is
                not capable of supporting control word in the
                encapsulation.
                - interface parameters specified in the VC LABEL object
                are not acceptable,
                - interface parameters specified in VC LABEL REQUEST
                object was not found in corresponding VC LABEL object.

        Ingress node SHOULD stop sending VC LABEL REQUEST objects in
        RSVP PATH messages if it detects that the egress node of the
        L2 channel is not operational.

        If ingress does not receive RESV replies with VC LABEL objects
        from the egress after certain timeout period, it SHOULD use
        methods appropriate in the L2 protocol to signal that the
        receiving side of the virtual circuit is not operational.  The
        signal SHOULD be sent to the L2 link that is being tunneled
        over MPLS network.

        If ingress wants to change the VC setup, it simply sends
        revised VC LABEL REQUEST objects in PATH messages.  The virtual
        circuit that does not have corresponding VC ID in the revised
        VC LABEL REQUEST object SHOULD be torn down.


   Cai           Internet Draft - Expires August 2001                6
            Signaling Virtual Circuit Label Using RSVP-TE February 2001

        If ingress wants to tear down a particular virtual circuit it
        SHOULD stop sending VC Label Request object in PATH messages.
        Alternatively it MAY also initiate the teardown procedure as
        defined in [4].

   Egress

        The egress node replies to VC LABEL REQUEST objects in PATH
        messages with VC LABEL objects in RESV messages. The egress
        node MUST NOT reply with LABEL object if:

                - the VC Type specified in the VC Label Request is not
                supported,
                - the specified VC ID does not match any configured
                virtual circuit
                - the VC Label Request object has the C bit set and
                the egress LSR is not capable of using control word
                in L2 PDU encapsulation.
                - interface parameters specified in the VC LABEL
                REQUEST object are not acceptable.
                - the receiving side of the L2 circuit related to the
                VC ID is not operational.

        The egress node MAY set the C bit to 1 in VC Label object if it
        requires the ingress node to use the control word in the
        encapsulation.  This may occur even if the VC Label Request
        object that has C bit set to zero. If interface parameter field
        is included in the VC LABEL REQUEST, egress LSR MUST include
        this field unchanged in the VC LABEL object. It MAY include
        interface parameter field in the VC LABEL object even if no
        such field was present in the corresponding VC LABEL REQUEST.

        If egress does not receive PATH messages with VC LABEL REQUEST
        objects after certain timeout period, it SHOULD use methods
        appropriate for the L2 protocol to signal that the sending side
        of the virtual circuit is not operational.  The signal should
        be sent on the L2 link that is being tunneled over MPLS
        network.

        If egress wants to change the VC setup, it simply sends revised
        VC LABEL objects in RESV messages.

        If egress wants to tear down a particular VC of L2 it SHOULD
        stop replying to the corresponding VC Label Requests.
        Alternatively it MAY also initiate the teardown procedure as
        defined [4].


Security Considerations

   This document does not affect the underlying security issues of
   MPLS.


   Cai           Internet Draft - Expires August 2001                7
            Signaling Virtual Circuit Label Using RSVP-TE February 2001

Acknowledgements

   We would like to thank Jeff Apple for reviewing the draft and Steve
   Cheek and Karel Zikan for their just-in-time help on editing the
   draft.

   Cai           Internet Draft - Expires August 2001                8
            Signaling Virtual Circuit Label Using RSVP-TE February 2001


References

1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997

2  "Transport of Layer 2 Frames Over MPLS", draft-martini-
l2circuit-trans-mpls-04.txt, Work in Progress.

3  "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-
lsp-tunnel-07.txt, Work in Progress.

4  RFC 2205 R. Branden, L.Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource Reservation Protococol (RSVP) -- Version 1 Functional
Specification", September, 1997

5  "Encapsulation Methods for Transport of Layer 2 Frames Over
MPLS", draft-martini-l2circuit-encap-mpls-01.txt, Work in Progress

Note: The RSVP class number 208 and 209 and their C-Types is pending
IANA approval.




Author's Addresses

   Martin Machacek
   Terabeam Networks, Inc.
   14833 NE 87th St.            Phone:
   Redmond, WA, USA             Email:  Martin.Machacek@Terabeam.com

   Ting Cai
   Terabeam Networks, Inc.
   14833 NE 87th St.            Phone: (206) 321-6367
   Redmond, WA, USA             Email:  Ting.Cai@terabeam.com

   Cai           Internet Draft - Expires August 2001                9