[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                        Fatai Zhang
Internet Draft                                                    Yi Lin
Category: Standards Track                                         Huawei

Expires: January 2011                                       July 4, 2010


       RSVP-TE extensions for TCM configuration in MPLS-TP network

            draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   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.

   This Internet-Draft will expire on January 4, 2011.

Abstract

   This specification describes the requirements of Tandem Connection
   Monitoring (TCM) configuration via GMPLS control plane in MPLS-TP
   network and provides the procedure of creating TCM path segment
   tunnel on a transport path to meet the requirements of TCM
   configuration.

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 [RFC2119].




Zhang                   Expires January 2011                   [Page 1]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


Table of Contents


   1. Introduction..................................................2
   2. Terminology...................................................3
   3. Requirements of TCM Configuration.............................3
      3.1. Introduction of TCM Path Segment Tunnel..................3
      3.2. Requirements of TCM Configuration Using RSVP-TE..........4
   4. Procedure of TCM Configuration................................5
      4.1. Path Segment Tunnel Creation.............................6
      4.2. LSP Rerouting in control plane...........................7
      4.3. OAM Configuration........................................7
   5. RSVP-TE Extension.............................................7
      5.1. TCM_CONFIGURATION object in PATH message.................8
      5.2. TCM_CONFIGURATION object in RESV message.................9
   6. Security Considerations.......................................9
   7. IANA Considerations...........................................9
   8. Acknowledgments...............................................9
   9. References....................................................9
   10. Authors' Addresses..........................................10


1. Introduction

   The MPLS Transport Profile (MPLS-TP) is being developed by ITU-T and
   IETF. The MPLS-TP data plane framework and requirements are described
   in [TP-FRWK] and [RFC5654], and the [TP-CP-FRWK] provides the
   framework to support dynamic provisioning of MPLS-TP transport paths
   via control plane.

   The MPLS-TP Operations, Administration and Maintenance (OAM), which
   is defined in [TP-OAM], is one of the most important and fundamental
   functionalities in MPLS-TP. The OAM functionality is not only applied
   on a transport path granularity, but also applied on arbitrary parts
   of the transport path, defined as Tandem Connections. For the latter
   case, a Tandem Connection Monitoring (TCM) is implemented by creating
   a path segment tunnel that has a 1:1 association with the path
   segment of the transport path that is to be uniquely monitored.
   Therefore, the LSP is nested into the TCM path segment tunnel.

   In case of TCM configuration using GMPLS control plane, the TCM path
   segment tunnel needs to be created on an in-service LSP, which is not
   supported in the current GMPLS RSVP-TE signaling.





Zhang                   Expires January 2011                   [Page 2]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


   This document provides the procedure of creating such outer layer
   path segment tunnel on a transport path via control plane to meet the
   requirement of automatic TCM configuration.



2. Terminology

   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 [RFC2119].

3. Requirements of TCM Configuration

3.1. Introduction of TCM Path Segment Tunnel

   This sub-section is informational which introduces the TCM and LSP
   Path Segment Tunnel Monitoring in the MPLS-TP data plane.

   As described in [TP-OAM], TCM is implemented by LSP Path Segment
   Tunnel Monitoring which can be deployed to monitor the behavior of a
   part of an LSP.

          |<---------------------- LSP ---------------------->|
          |                                                   |
          |           |<-- Path Segment Tunnel -->|           |
          |           |                           |           |
          +-----------+===========================+-----------+
          +-----------+===========================+-----------+
       +-----+      +-----+      +-----+      +-----+      +-----+
       |     |      |     |      |     |      |     |      |     |
       |  A  +------|  B  +------+  C  +------+  D  +------+  E  |
       |     |      |     |      |     |      |     |      |     |
       +-----+      +-----+      +-----+      +-----+      +-----+
             ------->     ------->     ------->     ------->
            +--+----+  +--+--+----+  +--+--+----+  +--+----+
     Data:  |L1|Data|  |L5|L3|Data|  |L6|L3|Data|  |L4|Data|
            +--+----+  +--+--+----+  +--+--+----+  +--+----+
                       +--+--+----+  +--+--+----+
     OAM packets:      |L5|13|OAM |  |L6|13|OAM |
                       +--+--+----+  +--+--+----+

               Figure 1 - Example of Path Segment Monitoring

   Figure 1 shows an example of TCM. Assume that there is an LSP passing
   through node A, B, C, D and E. A path segment tunnel between node B
   and D will be created when the operator wants to configure a TCM to


Zhang                   Expires January 2011                   [Page 3]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


   monitor this path segment. The path segment tunnel has a 1:1
   association with the LSP which is nested into this tunnel. In other
   words, the label stacking is performed between B and D, where the
   inner layer label is corresponded with the LSP and the outer layer
   label is corresponded with the tunnel.

   Since the data packets of the LSP and the OAM packets for path
   segment monitoring are using the same outer layer labels (i.e., the
   tunnel labels), the LSP and the OAM session can be associated.

3.2. Requirements of TCM Configuration Using RSVP-TE

   In most cases, the path segment tunnel for TCM is created when the
   LSP is in service. When the network operator wants to monitor a
   certain part of the LSP, a path segment tunnel needs to be set up by
   RSVP-TE if the GMPLS control plane is in use.

   Figure 2 and 3 show the label forwarding tables on each node that the
   LSP pass through before and after the creation of the tunnel. In the
   example shown in Figure 3, in order to create the TCM tunnel, the TCM
   source node B needs to create a new label forwarding entry with two
   labels, in which the in-label at the TCM destination node D of the
   LSP (i.e., the label "L3") is treated as the inner layer out-label.
   The current RSVP-TE can not support creation of such label forwarding
   entry and creation of TCM tunnel on an existing LSP, so RSVP-TE needs
   to be extended.

           |<---------------------- LSP ---------------------->|
           |                                                   |
           +---------------------------------------------------+
           +---------------------------------------------------+
        +-----+      +-----+      +-----+      +-----+      +-----+
        |     |      |     |      |     |      |     |      |     |
        |  A  +------|  B  +------+  C  +------+  D  +------+  E  |
        |     |      |     |      |     |      |     |      |     |
        +-----+      +-----+      +-----+      +-----+      +-----+

   +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
   |  Node A   | |  Node B   | |  Node C   | |  Node D   | |  Node E   |
   +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
   | in  | out | | in  | out | | in  | out | | in  | out | | in  | out |
   |label|label| |label|label| |label|label| |label|label| |label|label|
   +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
   | --  | L1  | | L1  | L2  | | L2  | L3  | | L3  | L4  | | L4  | POP |
   +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+

        Figure 2 - Label Forwarding Tables before Creation of Tunnel


Zhang                   Expires January 2011                   [Page 4]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010




           |<---------------------- LSP ---------------------->|
           |                                                   |
           |           |<-- Path Segment Tunnel -->|           |
           |           |                           |           |
           +-----------+===========================+-----------+
           +-----------+===========================+-----------+
        +-----+      +-----+      +-----+      +-----+      +-----+
        |     |      |     |      |     |      |     |      |     |
        |  A  +------|  B  +------+  C  +------+  D  +------+  E  |
        |     |      |     |      |     |      |     |      |     |
        +-----+      +-----+      +-----+      +-----+      +-----+

   +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
   |  Node A   | |  Node B   | |  Node C   | |  Node D   | |  Node E   |
   +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
   | in  | out | | in  | out | | in  | out | | in  | out | | in  | out |
   |label|label| |label|label| |label|label| |label|label| |label|label|
   +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
   | --  | L1  | | L1  |L3+L5| | L5  | L6  | | L6  | POP | | L4  | POP |
   +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
                                             | L3  | L4  |
                                             +-----+-----+

        Figure 3 - Label Forwarding Tables after Creation of Tunnel


   The basic requirements of setting up path segment tunnel on an LSP
   for TCM by GMPLS RSVP-TE signaling include:

      -  No Disruption of User Traffic on the LSP.

      -  The path segment tunnel MUST pass through exactly the same
         route as the LSP segment to be monitored.

      -  No extra bandwidth required. Since the tunnel and the LSP
         segment have a 1:1 relationship, the bandwidth of the tunnel is
         exactly the same as the LSP. Therefore, when setting up such
         tunnel, no extra bandwidth is required to be reserved.



4. Procedure of TCM Configuration

   When there is a need to monitor a part of an existing LSP between two
   nodes (i.e., the TCM source node and the TCM destination node), the


Zhang                   Expires January 2011                   [Page 5]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


   network operator can instruct the TCM source node to perform the TCM
   configuration. The GMPLS signaling is used to set up an RSVP-TE
   session for the TCM tunnel between TCM source node and destination
   node.



4.1. Path Segment Tunnel Creation

   If the OAM MEP function can be supported, the TCM source node sends a
   PATH message node by node along the LSP until the TCM destination
   node. The ERO, which indicates the same route as the LSP segment to
   be monitored, is necessary to be carried in this PATH message. The
   tunnel sender address and the tunnel end point address in the PATH
   message indicate the TCM source node and the TCM destination node.

   Additionally, in order to perform bandwidth sharing between the TCM
   tunnel and the LSP segment to be monitored, the PATH message for the
   TCM tunnel should indicate using Share Explicit (SE) reservation
   style and indicate which LSP to be monitored. Therefore, the
   information of source and destination node IDs and the LSP ID of the
   LSP to be monitored is needed to be carried in the PATH message.

   A new TCM_CONFIGURATION object, as described in Session 5, is
   introduced into the PATH message to carry this information.

   If the OAM MEP function can be supported, the TCM destination node
   responds a RESV message along the LSP until to the TCM source node.
   Each node on the TCM tunnel performs a normal label distribution
   procedure for the TCM tunnel and uses the SE style to share bandwidth
   resources with the LSP.

   Additionally, the TCM source node needs to use the in-label of the
   LSP at the TCM destination node (i.e., L3 in figure 2 and 3) to
   create the label forwarding entry for the TCM tunnel. But the TCM
   source node may not have this label information because the Label
   recording may not be performed in the LSP (i.e., the Label_Recording
   flag in the SESSION_ATTRIBUTE object of the LSP is not set).
   Therefore, the TCM destination node needs to include this in-label
   in the RESV message. This label will be forwarded to the TCM source
   node by the RESV messages sent by the intermediate nodes. This label
   can be also carried in the TCM CONFIGUARION object. See Session 5 for
   the detailed format of this object.

   In Figure 3, for the TCM source node B, three labels are obtained:

   -  L3 from the downstream RESV message;


Zhang                   Expires January 2011                   [Page 6]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


   -  The label of the TCM tunnel allocate by the downstream node (i.e.,
      L5 in figure 2 and 3) from the downstream RESV message;

   -  The in-label of the LSP on the TCM source node (i.e., L1 in figure
      2 and 3) from the forwarding entry related to the LSP on itself.

   Then the TCM source node can creates a new label forwarding entry
   which indicates that for the received data packet with a label of L1,
   the label is replaced to two layer label, where the inner layer label
   is L3 and the outer label is L5.

   At last, the TCM source node enables this new created label
   forwarding entry and disables the old one for the LSP, so that the
   TCM tunnel is created and is ready for use.



4.2. LSP Rerouting in control plane

   After setting up the TCM tunnel, the TCM tunnel is treated to be one
   hop in the viewpoint of the original LSP. In other words, the route
   of the LSP is changed so that a rerouting procedure is necessary to
   be performed in the control plane. A Notify message is sent from the
   TCM source node to the source node of the LSP to inform the change of
   the route, so that the source node of the LSP can refresh the LSP
   along the new route in the next refreshing periods.



4.3. OAM Configuration

   After setting up the TCM tunnel, the OAM function can be initiated.
   [OAM-CFG] describes the procedure of OAM configuration using GMPLS
   control plane.



5. RSVP-TE Extension

   A new TCM_CONFIGURATION object is introduced to carry the TCM related
   information. The object class is TBD.








Zhang                   Expires January 2011                   [Page 7]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


5.1. TCM_CONFIGURATION object in PATH message

   When the TCM_CONFIGURATION object is carried in the PATH message, the
   object carries the information of the monitored LSP.



   C_Type = 1:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                LSP source node IPv4 address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              LSP destination node IPv4 address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         MUST be zero          |            LSP ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   C-Type = 2:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                LSP source node IPv6 address                   |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              LSP destination node IPv6 address                |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         MUST be zero          |            LSP ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LSP source and destination node and the LSP ID are used to
   indicate which LSP to be monitored.








Zhang                   Expires January 2011                   [Page 8]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


5.2. TCM_CONFIGURATION object in RESV message

   When the TCM_CONFIGURATION object is carried in the RESV message, the
   object carries the in-label of the LSP at the TCM destination node.



   C-Type = 3:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           in-label of LSP at TCM destination node             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



6. Security Considerations

   TBD.

7. IANA Considerations

   TBD.

8. Acknowledgments

   TBD.

9. References

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

   [TP-FRWK]   M. Bocci et al, "A Framework for MPLS in Transport
               Networks", draft-ietf-mpls-tp-framework-06, October 16,
               2009.

   [RFC5654]   B. Niven-Jenkins et al, "Requirements of an MPLS
               Transport Profile", RFC 5654, September 2009.

   [TP-OAM]    I. Busi et al, "MPLS-TP OAM Framework", draft-ietf-mpls-
               tp-oam-framework-06, April 21, 2010.

   [RFC3945]   Mannie, E., "Generalized Multi-Protocol Label Switching
               (GMPLS) Architecture", RFC 3945, October 2004.



Zhang                   Expires January 2011                   [Page 9]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


   [TP-CP-FRWK] Loa Andersson et al, "MPLS-TP Control Plane Framework",
               draft-ietf-ccamp-mpls-tp-cp-framework-02, June 18, 2010.

   [OAM-CFG]   A. Takacs et al, "OAM Configuration Framework and
               Requirements for GMPLS RSVP-TE", draft-ietf-ccamp-oam-
               configuration-fwk-03, January 28, 2010.

   [RFC3471]   Berger, L., Ed., "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Functional Description", RFC
               3471, January 2003.

   [RFC3473]   L. Berger, Ed., "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Resource ReserVation
               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
               3473, January 2003.



10. Authors' Addresses

   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912
   Email: zhangfatai@huawei.com


   Yi Lin
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972914
   Email: linyi_hw@huawei.com





Intellectual Property



Zhang                   Expires January 2011                  [Page 10]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.


Disclaimer of Validity

   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE



Zhang                   Expires January 2011                  [Page 11]


draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt           July 2010


   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



























Zhang                   Expires January 2011                  [Page 12]