[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

CCAMP Working Group                                             F. Zhang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                           M. Venkatesan
Expires: April 15, 2013                                        Dell Inc.
                                                                   Y. Xu
                                                                    CATR
                                                               R. Gandhi
                                                           Cisco Systems
                                                        October 12, 2012


     RSVP-TE Identification of MPLS-TP Co-Routed Bidirectional LSP
           draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-05

Abstract

   The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370]
   specifies an initial set of identifiers, including the local assigned
   Z9-Tunnel_Num for co-routed bidirectional LSP, which is not covered
   by the current specifications, like [RFC3209], [RFC3473].  This
   document defines Resource ReserVation Protocol Traffic Engnieering
   (RSVP-TE) identification of MPLS-TP co-routed bidirectional LSP.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 15, 2013.

Copyright Notice

   Copyright (c) 2012 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



Zhang, et al.            Expires April 15, 2013                 [Page 1]


Internet-Draft   RSVP-TE ID of MPLS-TP Co-Routed Bi LSP     October 2012


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
   3.  MPLS-TP Co-Routed Bidirectional LSP Identification  . . . . . . 3
     3.1.  Signaling Procedures  . . . . . . . . . . . . . . . . . . . 3
     3.2.  Association Object  . . . . . . . . . . . . . . . . . . . . 4
     3.3.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative references  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7




























Zhang, et al.            Expires April 15, 2013                 [Page 2]


Internet-Draft   RSVP-TE ID of MPLS-TP Co-Routed Bi LSP     October 2012


1.  Introduction

   The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370]
   specifies a initial set of identifiers, such as the LSP_ID of of the
   MPLS-TP co-routed bidirectional LSP, which is A1-
   {Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num. The mapping
   from an MPLS-TP LSP_ID to Resource ReserVation Protocol Traffic
   Engnieering (RSVP-TE) is also descirbed in [RFC6370], except the
   local assigned Z9-Tunnel_Num, which is not covered by the current
   specifications, like [RFC3209], [RFC3473].  However, the Z9-
   Tunnel_Num is a part of the Maintenance Entity Point Identifier
   (MEP_ID), and the two MEP nodes must pre-store each other's MEP-IDs
   before sending some Operation, Administration and Maintenance (OAM)
   packets, such as Connectivity Verification (CV) [RFC6428].  In this
   way the peer endpoint can compare the received and expected MEP-IDs
   to judge whether there is a mis-connectivity defect [RFC6371].  In
   other words, A1/Z9 nodes need to know each other's Tunnel_Num.

   This document defines Resource ReserVation Protocol Traffic
   Engnieering (RSVP-TE) identification of MPLS-TP co-routed
   bidirectional LSP.  Since the LSP identifiers can be carried in an
   ASSOCIATION object [I-D.ietf-ccamp-assoc-ext], it is naturally to
   define the signaling extensions based on the ASSOCIATION object.


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


3.   MPLS-TP Co-Routed Bidirectional LSP Identification

3.1.  Signaling Procedures

   Consider that LSP1 is initialized at A1 node with an ASSOCIATION
   object inserted in Path message.  Association Type is set to "LSP
   Identifiers", Association ID set to A1-Tunnel_Num, Association Source
   set to A1-Node_ID.  Upon receipt of the Association Object, the
   egress node Z9 checks the Association Type field.  If it is "LSP
   Identifiers", the ASSOCIATION object MUST be carried in the Resv
   message also.  Similarly, Association Type is set to "LSP
   Identifiers", Association ID set to Z9-Tunnel_Num, Association Source
   set to Z9-Node_ID.  In this way, the ingress LSR can get the Z9-
   Tunnel_Num, which MAY be used for identifying a mis-connectivity
   defect of the proactive CV OAM function.




Zhang, et al.            Expires April 15, 2013                 [Page 3]


Internet-Draft   RSVP-TE ID of MPLS-TP Co-Routed Bi LSP     October 2012


   If LSP1 is across different domains, A1 and Z9 nodes MAY need to know
   each other's Global_ID also.  When an Extended ASSOCIATION object
   with Association Type "LSP Identifiers" in inserted in the
   initialized LSP Path message, Global Association Source is set to A1-
   Global_ID.  Similarly, this field will be set to Z9-Global_ID in the
   Resv message.

3.2.  Association Object

   Within the current document, a new Association Type is defined in the
   ASSOCIATION object, which MAY be used with any ASSOCIATION object
   type.  For example, the Extended ASSOCIATION object defined in
   [I-D.ietf-ccamp-assoc-ext] can be used when Global_ID based
   identification is desired.


   Value      Type
   -----      -----
   6 (TBD)    LSP Identifiers (L)


   Association ID: 16 bits

      For Path message, Association ID is the Tunnel_Num of the node
      sending out the Path message, and can be ignored by the receiver.

      For Resv message, Association ID is the Tunnel_Num of the node
      sending out the Resv message.

   Association Source: 4 or 16 bytes

      Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].

      For Path message, Association Source is the IP address of the node
      sending out the Path message, and can be ignored by the receiver.

      For Resv message, Association Source is the IP address of the node
      sending out the Resv message, and can be ignored by the receiver.

   Global Association Source: 4 bytes

      Same as defined in [I-D.ietf-ccamp-assoc-ext] if Extended
      ASSOCIATION object is used.

      For Path message, Global Association Source is filled with the
      Global_ID of the node sending out the Path message.





Zhang, et al.            Expires April 15, 2013                 [Page 4]


Internet-Draft   RSVP-TE ID of MPLS-TP Co-Routed Bi LSP     October 2012



      For Resv message, Global Association Source is the Global_ID of
      the node sending out the Resv message.

   Extended Association ID:

      Extended Association ID is not added in the Extended ASSOCIATION
      object when association type signaled is "LSP Identifiers".

   The rules associated with the processing of the Extended ASSOCIATION
   objects in RSVP message are discussed in [I-D.ietf-ccamp-assoc-ext].
   It said that in the absence of Association Type-specific rules for
   identifying association, the included ASSOCIATION objects MUST be
   identical.  Since the Association Type "LSP Identifiers" used here is
   to carry LSP identifier, there is no need to associate Path state to
   Path state or Resv state to Resv state, one specific rule is added:
   when the Association Type is "LSP Identifiers", the ASSOCIATION
   object can appear in Path or Resv message across sessions or in a
   single session, and the values can be different.

3.3.  Compatibility

   Per [RFC4872], the ASSOCIATION object uses an object class number of
   the form 11bbbbbb to ensure compatibility with non-supporting nodes.
   Per [RFC2205], such nodes will ignore the object but forward it
   without modification.  This is also described in
   [I-D.ietf-ccamp-assoc-ext].

   Per [RFC4872], transit nodes that support the ASSOCIATION object, but
   not the Extended Association C-Types, will "transmit, without
   modification, any received ASSOCIATION object in the corresponding
   outgoing Path message."  Per [RFC2205], an egress node that supports
   the ASSOCIATION object, but not the Extended Association C-Types may
   generate an "Unknown object C-Type" error.  This error will propagate
   to the ingress node for standard error processing.

   Operators wishing to use a function supported by the association type
   "LSP Identifiers" should ensure that the type is supported on any
   node which is expected to act on the association.


4.  IANA Considerations

   IANA is requested to administer assignment of new values for
   namespace defined in this document and summarized in this section.

   One value ("LSP Identifiers") needs to be allocated in the
   Association Type Registry.



Zhang, et al.            Expires April 15, 2013                 [Page 5]


Internet-Draft   RSVP-TE ID of MPLS-TP Co-Routed Bi LSP     October 2012


5.  Security Considerations

   A new Association Type is defined in this document, and except this,
   there are no security issues about the ASSOCIATION object and
   Extended ASSOCIATION object are introduced here.  For Association
   object related security issues, see the documents [RFC4872],
   [RFC4873], and [I-D.ietf-ccamp-assoc-ext].

   For a more comprehensive discussion on GMPLS security please see the
   Security Framework for MPLS and GMPLS Networks [RFC5920].


6.  Acknowledgement

   This document was prepared based on the discussion with George
   Swallow, valuable comments and input were also received from Lou
   Berger, John E Drake, Jaihari Kalijanakiraman, Muliu Tao and Wenjuan
   He.


7.  References

7.1.  Normative references

   [I-D.ietf-ccamp-assoc-ext]
              Berger, L., Faucheur, F., and A. Narayanan, "RSVP
              Association Object Extensions",
              draft-ietf-ccamp-assoc-ext-06 (work in progress),
              September 2012.

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

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

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







Zhang, et al.            Expires April 15, 2013                 [Page 6]


Internet-Draft   RSVP-TE ID of MPLS-TP Co-Routed Bi LSP     October 2012


7.2.  Informative References

   [RFC4872]  Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
              Extensions in Support of End-to-End Generalized Multi-
              Protocol Label Switching (GMPLS) Recovery", RFC 4872,
              May 2007.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, May 2007.

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.

   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
              Maintenance Framework for MPLS-Based Transport Networks",
              RFC 6371, September 2011.

   [RFC6428]  Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
              Connectivity Verification, Continuity Check, and Remote
              Defect Indication for the MPLS Transport Profile",
              RFC 6428, November 2011.


Authors' Addresses

   Fei Zhang
   ZTE Corporation

   Email: zhang.fei3@zte.com.cn


   Venkatesan Mahalingam
   Dell Inc.

   Email: venkat.mahalingams@gmail.com


   Yunbin Xu
   CATR

   Email: xuyunbin@mail.ritt.com.cn







Zhang, et al.            Expires April 15, 2013                 [Page 7]


Internet-Draft   RSVP-TE ID of MPLS-TP Co-Routed Bi LSP     October 2012


   Rakesh Gandhi
   Cisco Systems

   Email: rgandhi@cisco.com


   Xiao Bao
   ZTE Corporation

   Email: bao.xiao1@zte.com.cn









































Zhang, et al.            Expires April 15, 2013                 [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/