MPLS
CCAMP Working Group                                             F. Zhang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                          March 07, 2012                           M. Venkatesan
Expires: September 8, December 08, 2012                                     Dell Inc.
                                                                   Y. Xu
                                                                    CATR
                                                           June 08, 2012

       RSVP-TE Extensions to Exchange MPLS-TP LSP Identifiers
           draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 Tunnnel Numbers
           draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03

Abstract

   The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370]
   specifies an initial set of identifiers, such as including the local assigned
   tunnel number and Global_ID,
   Z9-Tunnel_Num, which can be used to form Maintenance Entity Point
   Identifier (MEP_ID).  As to some Operation, Administration and
   Maintenance (OAM) functions, such as Connectivity Verification (CV)
   [RFC6428], source MEP_ID must be inserted in the OAM packets, so that
   the peer endpoint can compare the received and expected MEP_IDs to
   judge whether there is a mismatch mis-connnectivity defect [RFC6371], which
   means that the two MEP nodes need to pre-store each other's MEP_IDs.

   This document defines the signaling extensions to exchange communicate the Label
   Switched Path (LSP) identifiers.
   local assigned Z9-Tunnel_Num to the ingress LSR (Label Switching
   Router) of a 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 September 8, December 08, 2012.

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3  2
   2.  Conventions used in this document  . . . . . . . . . . . . . . . 3  2
   3.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Co-routed Bidirectional LSP . . . . . . . . . . . . . . . .  3
     3.2.  Associated Bidirectional LSP  . . . . . . . . . . . . . . . 4
   4.  RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 5  3
     4.1.  Association Type . . . . . . . . . . . . . . . . . . . . . 5  3
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 5  3
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . . 5  4
   7.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . . 6  4
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 6  4
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 6  4
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 6
   Author's Address  .  4
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7  5

1.  Introduction

   The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370]
   specifies a initial set of identifiers, such as including the local assigned tunnel
   number (Tunnel_Num) and Global_ID,
   Z9-Tunnel_Num, which can be used to form Maintenance Entity Point
   Identifier (MEP_ID).  The MPLS-TP LSP_MEP_ID is
   Node_ID::Tunnel_Num::LSP_Num, and in situations where global
   uniqueness is required, this becomes: Global_ID::Node_ID::
   Tunnel_Num::LSP_Num.
   Global_ID::Node_ID::Tunnel_Num::LSP_Num.  In order to realize some
   Operation, Administration and Maintenance (OAM) functions, such as
   Connectivity Verification (CV) [RFC6428], source MEP-ID MUST be
   inserted in the OAM packets, in this way the peer endpoint can
   compare the received and expected MEP-IDs to judge whether there is a mismatch
   mis-connnectivity defect [RFC6371].  Hence, the two MEP nodes must
   pre-store each other's MEP-IDs before sending the CV packets.

   Obviously, the exchange of MEP_IDs can be accomplished by the Network
   Management System (NMS), but it is complex when the LSPs cross
   different adiminstration domains, which involves the cooperation of
   NMSs.

   When the LSPs are set up by control plane, Resource ReserVation
   Protocol Traffic Engnieering (RSVP-TE) messages will can be
   more suitable used to
   communicate the Z9-Tunnel_Num to realize the exchange ingress LSR (Label Switching
   Router) of MEP_IDs. a co-routed bidirectional LSP. Since the LSP identifiers
   can be carried in an Extended ASSOCIATION object, which may also be used in a
   single session [I-D.ietf-ccamp-assoc-ext], it is naturally to define
   the signaling extensions of co-routed and associated bidirectional LSP to exchange
   the LSP identifiers based on the Extended 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.  Operation

3.1.  Co-routed Bidirectional LSP

   Consider that LSP1 is across different administration domains, which
   is initialized at A1 node with an Extended ASSOCIATION
   object inserted in Path message.  Association Type is set to "LSP
   Identifers", Association ID set to A1-Tunnel_Num, Association Source
   set to A1-Node_ID, Global Association Source set to A1-Global_ID, and
   the Extended Association ID field is omitted. A1-Node_ID. Upon receipt of the
   Extended Association Object, the terminating egress
   node Z9 checks the Association Type field.  If it is "LSP
   Identifiers" and an Upstream_Label exists in Path message, the Extended
   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, Global
   Association Source set to Z9-Global_ID, and the Extended Association
   ID field is omitted.

3.2.  Associated Bidirectional LSP

   The document [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]
   discusses Z9-Node_ID. In
   this way, the provisioning models and signaling procedures of
   associated bidirectional LSPs.  Consider ingress LSR can get the example provided there,
   when LSP1 and LSP2 are bound together to be an associated
   bidirectional LSP Z9-Tunnel_Num, which is across several administration domains, the
   global ID filled in the Extended Association objects with Association
   Type set to "Double Sided Associated Bidirectional LSP" or "Single
   Sided Associated Bidirectional LSP" is A-Global_ID or B-Global_ID.
   If it is A-Global_ID, node A still does know the global ID of node B
   in case that LSP1 and LSP2 are across several administration domains.
   Since multiple Association objects have always been supported in Path
   messages, an Extended Association object with Asssociation Type "LSP
   Identifiers" can may be inserted in the Path messages of associated
   bidirectional LSPs to let the terminating nodes exchange each others
   LSP identifiers.

   If double sided provisioning model is used, the values
   used for identifying a mis-connnectivity defect of an Extended
   Association object in LSP1's Path message are set as below :
   Association Type set to "LSP Identifiers", Association ID set to
   A-Tunnel_Num, Association Source set to A-Node_ID, Global Association
   Source set to A-Global_ID, and the Extended Association ID field
   omitted; the object in LSP2's Path message are set similarly :
   Association Type is set to "LSP Identifiers", Association ID set to
   B-Tunnel_Num, Association Source set to B-Node_ID, Global Association
   Source set to B-Global_ID, and the Extended Association ID field
   omitted.  While in case that single sided provisioning model is
   adopted, in the initialized LSP1's Path message, the values of an
   Extended Association object are set as following: Association Type
   set to "LSP Identifiers", Association ID set to A-Tunnel_Num,
   Association Source set to A-Node_ID, Global Association Source set to
   A-Global_ID, and the Extended Association ID field omitted.  When
   node B receives this Path message, LSP2 is triggered to be
   established by the received Extended ASSOCIATION objects with the
   Association Type "Single Sided Associated Bidirectional LSPs" and
   "LSP Identifiers".  The Extended Association Object with Association
   Type "LSP Identifiers" inserted in LSP2's Path message is like:
   Association ID set to B-Tunnel_Num, Association Source set to
   B-Node_ID, Global Association Source set to B-Global_ID, and the
   Extended Association ID field omitted. proactive CV
   OAM function.

4.  RSVP-TE Extensions

4.1.  Association Type

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

   See [I-D.ietf-ccamp-assoc-ext] for the definition of other fields and
   values.

   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 Extended 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 Extended ASSOCIATION
   object can appear in Path or Resv message across sessions or in a
   single session, and the values can be different.

5.  IANA Considerations

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

   One bit ("LSP Identifers") needs to be allocated in the Association
   Type Registry.

6.  Security Considerations

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

7.  Acknowledgement

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

8.  References

8.1.  Normative references

   [I-D.ietf-ccamp-assoc-ext]
              Berger, L., Faucheur, F., F. and A. Narayanan, "RSVP
              Association Object Extensions",
              draft-ietf-ccamp-assoc-ext-02 (work in progress),
              February Internet-Draft draft-ietf-
              ccamp-assoc-ext-03, March 2012.

   [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]
              Zhang, F. and R. Jing, "RSVP-TE Extensions for Associated
              Bidirectional LSPs",
              draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02
              (work in progress), October 2011.

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

8.2.  Informative References

   [RFC4872]  Lang, J., J.P., Rekhter, Y., 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., 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., 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., G. and J. Drake Ed.  ,
              "Proactive Connectivity Verification, Continuity Check,
              and Remote Defect Indication for the MPLS Transport
              Profile", RFC 6428, November 2011.

Author's Address

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

   Xiao Bao
   ZTE Corporation

   Email: bao.xiao1@zte.com.cn