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]