MPLS Working Group                                              F. Zhang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                      September 16,                       November 13, 2011
Expires: March 19, May 16, 2012

         RSVP-TE Extentions Extensions to Exchange MPLS-TP Tunnel Numbers
           draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 LSP Identifiers
           draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01

Abstract

   The MPLS Transport Profile (MPLS-TP) identifiers document
   [I-D.ietf-mpls-tp-identifiers] introduce two [RFC6370]
   specifies a initial set of identifiers, such as local assigned tunnel numbers, A1-
   Tunnel_Num
   number and Z9-Tunnel_Num, Global_ID, which allow a compact format for can be used to form Maintenance Entity
   Point Identifier (MEP_ID).  For  As to some Operation, Administration and
   Maintenance (OAM) functions, such as Connectivity Verification (CV)
   [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP_ID MUST 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, mismatch [RFC6371],
   which means that the two MEP nodes need to pre-store each other's
   MEP_IDs.

   The specification of setting up co-routed bidirectional LSP is
   described in the document [RFC3473], which does not introduce the
   locally configured tunnel number on the tunnel endpoint.

   This document defines the Connection object signaling extensions to exchange the tunnel
   numbers. Label
   Switched Path (LSP) identifiers.

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 March 19, May 16, 2012.

Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
   3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Co-routed Bidirectional LSP . . . . . . . . . . . . . . . . 3
     3.2.  Associated Bidirectional LSP  . . . . . . . . . . . . . . . 4
   4.  RSVP-TE Extensions  . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  LSP Attribute Flags . . . . . . . . . . . . . . . . . . . . 5
     4.2.  Connection Object TLV  . . . . . . . . . . . . . . . . . . . . . . 5
     4.3.  Global_ID TLV . . 4 . . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7
     8.1.  Normative references  . . . . . . . . . . . . . . . . . . . 6 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6 8

1.  Introduction

   The MPLS Transport Profile (MPLS-TP) identifiers document
   [I-D.ietf-mpls-tp-identifiers] introduce two [RFC6370]
   specifies a initial set of identifiers, such as local assigned tunnel numbers, A1-
   Tunnel_Num
   number (Tunnel_Num) and Z9-Tunnel_Num, Global_ID, which are locally assigned and allow a
   compact format for can be used to form
   Maintenance Entity Point Identifier (MEP_ID).  For
   a co-routed bidirectional LSP, the format of A1-MEP_ID  The MPLS-TP LSP_MEP_ID
   is A1-
   Node_ID::A1-Tunnel_Num::LSP_Num, Node_ID::Tunnel_Num::LSP_Num, and the format of Z9-MEP_ID in situations where global
   uniqueness is Z9-
   Node_ID::Z9-Tunnel_Num::LSP_Num. required, this becomes: Global_ID::Node_ID::
   Tunnel_Num::LSP_Num. In order to realize some Operation,
   Administration and Maintenance (OAM) functions, such as Connectivity
   Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], 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.
   mismatch [RFC6371].  Hence, the two MEP nodes must pre-store each
   other's MEP-
   IDs MEP-IDs before sending the CV packets.

   Although

   Obviously, the exchange of MEP_IDs can be accomplished by the Network
   Management System (NMS) if it is deployed, (NMS), but it is still complex when the LSPs cross
   different adiminstration domains, which needs involves the cooperation of
   NMSs.  So when  When the LSPs are set up by control plane, Resource
   ReserVation Protocol Traffic Engnieering (RSVP-TE) signaling messages will be
   more suitable to realize the exchange of MEP_IDs.

   The specification of setting up co-routed bidirectional LSP is
   described in the document [RFC3473], which does not introduce specify the
   Global_ID and locally configured tunnel number on Z9-Tunnel_Num. Similary, for
   associated bidirectional LSP
   [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp], the tunnel endpoint. Global_ID may
   also be useful.  This document defines the Connection object signaling extensions to
   exchange the tunnel
   numbers. LSP identifiers.

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

   MPLS-TP co-routed bidirectional LSPs can be deloyed deployed across one or
   more administration domains, and NMS may exist in some administration
   domains, which knows the tunnel spaces of every node in it's
   responsible domain.  Consider that LSP1 is initialized at A1 node
   with Connection object inserted in LSP1's Path message , node,
   and the
   following modes may happend.

   Modes 1: L "L" bit of the Attributes Flags TLV [RFC5420] may be set in
   the outgoing Path message.  If the "L" bit is set, the Connection TLV
   MUST be carried and Global_ID TLV is optional in the Z9-Tunnel_Num LSP_ATTRIBUTES
   object.

   A "L" bit is defined in the Connection TLV.  When it is set, the Z9-
   Tunnel_Num is designated in the "Destination Tunnel Num" field.  If
   the Z9 node finds that this tunnel number is occupied, or it can not
   be used because of some local policies, a PathErr message must an error MUST be sent with "Unavailable generated
   "Notify error/ unavailable tunnel number" error. number".  Otherwise, the designated
   tunnel number must be adopted, and the Connection object TLV may be inserted
   in the Resv message without any change.

   Modes 2: L  In case the "L" bit is not
   set, and a recommended Z9-Tunnel_Num may be filled in the "Destination
   Tunnel Num" field.  If the Z9 node finds that the recommended value
   can be used, the Connection object TLV must be inserted in the Resv message
   without any change; if else the recommended value can not be used or the
   "Destination Tunnel Num" field is empty, a new tunnel number will be
   allocated and filled into the Connection
   object TLV that must be inserted in
   the Resv message.

   Each mode has its own pros and cons and how to determine  While, that the right
   mode for a specific network mainly "L" bit is set or not depends on
   the operators' preference.  For example, for the operators who are
   used to operate traditional transport network and familiar with the
   Transport-Centric operational model may prefer mode 1.  The second mode "L" bit set.  That the
   "L" bit is not set is more suitable for the operators who are
   familiar with the operation and maintenance of IP/MPLS network, or
   the MPLS-TP LSPs cross multiple administration domains.

4.  Connection Object

   The format of Connection Object (Class-Num Global_ID TLV is needed to be carried if the LSP is across
   different administrative domains, which can be inserted in the
   outgoing Path message at A1 node or added by the transit Autonomous
   System Border Router (ASBR) node that is in the same domain as A1
   node, and the value is A1's Global_ID.  Z9's Global_ID should be
   inserted in the Resv message at Z9 node or any other Label Swithed
   Routers (LSRs) that in the same domain as Z9, and the value is Z9's
   Global_ID.

3.2.  Associated Bidirectional LSP

   MPLS-TP associated bidirectional LSPs may also be deployed across one
   or more administration domains, and the Global_ID is needed to keep
   the MEP_ID globally unique.  Consider that the forward LSP is
   initialized at A1 node and the backward LSP is initialized at Z9
   node, the "L" bit of the form 11bbbbbb Attributes Flags TLV may be set in each
   other's outgoing Path messages.  When the "L" bit is set, the
   Global_ID TLV with the value = TBA, C-Type = TBA) set to A1/Z9's Global_ID is optional in
   the LSP_ATTRIBUTES object and can be inserted in the outgoing Path
   message at A1/Z9 node or added by the transit Autonomous System
   Border Router (ASBR) node that is in the same domain as follow: A1/Z9 node.
   If this TLV is present in Resv message, it can be ignored.

4.  RSVP-TE Extensions

4.1.  LSP Attribute Flags

   The LSP Attribute Flags TLV is defined in [RFC5420], and this
   document introduces a new flag:

   One bit ("L", IANA to assign): "LSP identifier indication" is
   allocated in the LSP Attributes Flags TLV to be used in the
   LSP_ATTRIBUTES object.  If the "L" bit is set, it is indicating that
   A1/Z9 node needs to know each other's LSP identifer.

4.2.  Connection TLV

   The Connection TLV is carried in the LSP_ATTRIBUTES object with 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Length            Type (TBD)         | Class-Num(TBA)|  C-Type (TBA)              Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|            Reserverd         Reserved            |       Destination Tunnel Num  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Connection Object TLV

   L

       The L bit is set if the initiating node enforces the peer
       endpoint to configure the value carried in the field of
       "Destination Tunnle Num".

       If the bit is not set, the peer endpoint firstly tries to
       use the recommended tunnel number; it can use any other
	   unoccupied tunnnel numbers when the recommended tunnel
	   number is unavailable.

   Reserverd

       Must be set to 0 on transmit and ignored on receive.

   Destination Tunnel Num

       If the L bit is set, it indicates that the peer endpoint
	   must configure the value carried in this field.

       If

	   Else the L bit is not set, this field can be empty or filled
	   by the recommended value.

   The Connection object TLV may appear in Path or Resv message, and a
   midpoint that does not support this object message of co-routed
   bidirectional LSP.

4.3.  Global_ID TLV

   The Global_ID TLV is required carried in the LSP_ATTRIBUTES object with 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Type (TBD)         |              Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Global_ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               Global_ID TLV

   This TLV can be used for co-routed or associated bidirectional LSP.
   For co-routed bidirectional LSP, it can appear in Path or Resv
   message.  As to pass associated bidirectional LSP, it on
   unaltered, as indicated by can only appear in
   the C-Num Path message, and the rules defined will be ignored in
   [RFC2205]. the Resv message.

5.  IANA Considerations

   TBD.

   One bit ("LSP identifier indication") needs to be allocated in the
   LSP Attributes Flags Registry.

   This document specifies two new TLVs to be carried in the
   LSP_ATTRIBUTES objects in Path and Resv messages: the Connection TLV
   and Global_ID TLV.

   For the existing error code "Notify error" (value 25), one new Error
   value: "Unavailable tunnel number" needs to be assigned.

6.  Security Considerations

   TBD.

   This document adds a new flag to the Attributes Flags TLV and
   introduce two new TLVs in the LSP_ATTRIBUTES objects.  It does not
   introduce any new direct security issues, and the reader is referred
   to the security considerations expressed in [RFC2205] and [RFC5420].

   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 was were also received from Berger
   Lou, Venkatesan Mahalingam Mahalingam, Jaihari Kalijanakiraman and Muliu Tao.

8.  References

8.1.  Normative references

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

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

   [RFC5420]  Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangarps, "Encoding of Attributes for MPLS LSP
              Establishment Using Resource Reservation Protocol Traffic
              Engineering (RSVP-TE)", RFC 5420, February 2009.

8.2.  Informative References

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

   [I-D.ietf-mpls-tp-cc-cv-rdi]
              Allan, D., Swallow, G., and J. Drake, "Proactive
              Connectivity Verification, Continuity Check and Remote
              Defect indication for MPLS Transport Profile",
              draft-ietf-mpls-tp-cc-cv-rdi-06 (work in progress),
              August 2011.

   [I-D.ietf-mpls-tp-identifiers]

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

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS-TP "MPLS Transport
              Profile (MPLS-TP) Identifiers", draft-ietf-mpls-tp-identifiers-07 (work in
              progress), July RFC 6370, September 2011.

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

Author's Address

   Fei Zhang
   ZTE Corporation

   Email: zhang.fei3@zte.com.cn

   Xiao Bao
   ZTE Corporation

   Email: bao.xiao1@zte.com.cn