draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00.txt   draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01.txt 
MPLS Working Group F. Zhang MPLS Working Group F. Zhang
Internet-Draft ZTE Corporation Internet-Draft ZTE Corporation
Intended status: Standards Track September 16, 2011 Intended status: Standards Track November 13, 2011
Expires: March 19, 2012 Expires: May 16, 2012
RSVP-TE Extentions to Exchange MPLS-TP Tunnel Numbers RSVP-TE Extensions to Exchange MPLS-TP LSP Identifiers
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01
Abstract Abstract
The MPLS Transport Profile (MPLS-TP) identifiers document The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370]
[I-D.ietf-mpls-tp-identifiers] introduce two tunnel numbers, A1- specifies a initial set of identifiers, such as local assigned tunnel
Tunnel_Num and Z9-Tunnel_Num, which allow a compact format for number and Global_ID, which can be used to form Maintenance Entity
Maintenance Entity Point Identifier (MEP_ID). For some Operation, Point Identifier (MEP_ID). As to some Operation, Administration and
Administration and Maintenance (OAM) functions, such as Connectivity Maintenance (OAM) functions, such as Connectivity Verification (CV)
Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP_ID MUST be [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP_ID must be inserted in the
inserted in the OAM packets, so that the peer endpoint can compare OAM packets, so that the peer endpoint can compare the received and
the received and expected MEP_IDs to judge whether there is a expected MEP_IDs to judge whether there is a mismatch [RFC6371],
mismatch, which means that the two MEP nodes need to pre-store each which means that the two MEP nodes need to pre-store each other's
other's MEP_IDs. MEP_IDs.
The specification of setting up co-routed bidirectional LSP is This document defines the signaling extensions to exchange the Label
described in the document [RFC3473], which does not introduce the Switched Path (LSP) identifiers.
locally configured tunnel number on the tunnel endpoint. This
document defines the Connection object to exchange the tunnel
numbers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 19, 2012. This Internet-Draft will expire on May 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 18
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Connection Object . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Co-routed Bidirectional LSP . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Associated Bidirectional LSP . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. LSP Attribute Flags . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Connection TLV . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative references . . . . . . . . . . . . . . . . . . . 6 4.3. Global_ID TLV . . . . . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative references . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) identifiers document The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370]
[I-D.ietf-mpls-tp-identifiers] introduce two tunnel numbers, A1- specifies a initial set of identifiers, such as local assigned tunnel
Tunnel_Num and Z9-Tunnel_Num, which are locally assigned and allow a number (Tunnel_Num) and Global_ID, which can be used to form
compact format for Maintenance Entity Point Identifier (MEP_ID). For Maintenance Entity Point Identifier (MEP_ID). The MPLS-TP LSP_MEP_ID
a co-routed bidirectional LSP, the format of A1-MEP_ID is A1- is Node_ID::Tunnel_Num::LSP_Num, and in situations where global
Node_ID::A1-Tunnel_Num::LSP_Num, and the format of Z9-MEP_ID is Z9- uniqueness is required, this becomes: Global_ID::Node_ID::
Node_ID::Z9-Tunnel_Num::LSP_Num. In order to realize some Operation, Tunnel_Num::LSP_Num. In order to realize some Operation,
Administration and Maintenance (OAM) functions, such as Connectivity Administration and Maintenance (OAM) functions, such as Connectivity
Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP-ID MUST be 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 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 compare the received and expected MEP-IDs to judge whether there is a
mismatch. Hence, the two MEP nodes must pre-store each other's MEP- mismatch [RFC6371]. Hence, the two MEP nodes must pre-store each
IDs before sending the CV packets. other's MEP-IDs before sending the CV packets.
Although the exchange of MEP_IDs can be accomplished by Network Obviously, the exchange of MEP_IDs can be accomplished by the Network
Management System (NMS) if it is deployed, it is still complex when Management System (NMS), but it is complex when the LSPs cross
the LSPs cross different adiminstration domains, which needs the different adiminstration domains, which involves the cooperation of
cooperation of NMSs. So when the LSPs are set up by control plane, NMSs. When the LSPs are set up by control plane, Resource
Resource ReserVation Protocol Traffic Engnieering (RSVP-TE) signaling ReserVation Protocol Traffic Engnieering (RSVP-TE) messages will be
will be more suitable to realize the exchange of MEP_IDs. more suitable to realize the exchange of MEP_IDs.
The specification of setting up co-routed bidirectional LSP is The specification of setting up co-routed bidirectional LSP is
described in the document [RFC3473], which does not introduce the described in the document [RFC3473], which does not specify the
locally configured tunnel number on the tunnel endpoint. This Global_ID and locally configured Z9-Tunnel_Num. Similary, for
document defines the Connection object to exchange the tunnel associated bidirectional LSP
numbers. [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp], the Global_ID may
also be useful. This document defines the signaling extensions to
exchange the LSP identifiers.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Operation 3. Operation
MPLS-TP co-routed bidirectional LSPs can be deloyed across one or 3.1. Co-routed Bidirectional LSP
MPLS-TP co-routed bidirectional LSPs can be deployed across one or
more administration domains, and NMS may exist in some administration more administration domains, and NMS may exist in some administration
domains, which knows the tunnel spaces of every node in it's domains, which knows the tunnel spaces of every node in it's
responsible domain. Consider that LSP1 is initialized at A1 node responsible domain. Consider that LSP1 is initialized at A1 node,
with Connection object inserted in LSP1's Path message , the and the "L" bit of the Attributes Flags TLV [RFC5420] may be set in
following modes may happend. the outgoing Path message. If the "L" bit is set, the Connection TLV
MUST be carried and Global_ID TLV is optional in the LSP_ATTRIBUTES
object.
Modes 1: L bit is set, and the Z9-Tunnel_Num is designated in the A "L" bit is defined in the Connection TLV. When it is set, the Z9-
"Destination Tunnel Num" field. If the Z9 node finds that this Tunnel_Num is designated in the "Destination Tunnel Num" field. If
tunnel number is occupied, or it can not be used because of some the Z9 node finds that this tunnel number is occupied, or it can not
local policies, a PathErr message must be sent with "Unavailable be used because of some local policies, an error MUST be generated
tunnel number" error. Otherwise, the designated tunnel number must "Notify error/ unavailable tunnel number". Otherwise, the designated
be adopted, and the Connection object may be inserted in the Resv tunnel number must be adopted, and the Connection TLV may be inserted
message without any change. in the Resv message without any change. In case the "L" bit is not
set, 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 TLV must be inserted in the Resv message
without any change; 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 TLV that must be inserted in
the Resv message. While, that the "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 "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.
Modes 2: L bit is not set, and a recommended Z9-Tunnel_Num may be The Global_ID TLV is needed to be carried if the LSP is across
filled in the "Destination Tunnel Num" field. If the Z9 node finds different administrative domains, which can be inserted in the
that the recommended value can be used, the Connection object must be outgoing Path message at A1 node or added by the transit Autonomous
inserted in the Resv message without any change; if the recommended System Border Router (ASBR) node that is in the same domain as A1
value can not be used or the "Destination Tunnel Num" field is empty, node, and the value is A1's Global_ID. Z9's Global_ID should be
a new tunnel number will be allocated and filled into the Connection inserted in the Resv message at Z9 node or any other Label Swithed
object that must be inserted in the Resv message. Routers (LSRs) that in the same domain as Z9, and the value is Z9's
Global_ID.
Each mode has its own pros and cons and how to determine the right 3.2. Associated Bidirectional LSP
mode for a specific network mainly 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 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 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 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 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 A1/Z9 node.
If this TLV is present in Resv message, it can be ignored.
The format of Connection Object (Class-Num of the form 11bbbbbb with 4. RSVP-TE Extensions
value = TBA, C-Type = TBA) is as follow:
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
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 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 | Class-Num(TBA)| C-Type (TBA) | | Type (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserverd | Destination Tunnel Num | |L| Reserved | Destination Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Connection Object Connection TLV
L L
The L bit is set if the initiating node enforces the peer The L bit is set if the initiating node enforces the peer
endpoint to configure the value carried in the field of endpoint to configure the value carried in the field of
"Destination Tunnle Num". "Destination Tunnle Num".
If the bit is not set, the peer endpoint firstly tries to If the bit is not set, the peer endpoint firstly tries to
use the recommended tunnel number; it can use any other use the recommended tunnel number; it can use any other
unoccupied tunnnel numbers when the recommended tunnel unoccupied tunnnel numbers when the recommended tunnel
skipping to change at page 5, line 25 skipping to change at page 6, line 25
Reserverd Reserverd
Must be set to 0 on transmit and ignored on receive. Must be set to 0 on transmit and ignored on receive.
Destination Tunnel Num Destination Tunnel Num
If the L bit is set, it indicates that the peer endpoint If the L bit is set, it indicates that the peer endpoint
must configure the value carried in this field. must configure the value carried in this field.
If the L bit is not set, this field can be empty or filled Else the L bit is not set, this field can be empty or filled
by the recommended value. by the recommended value.
The Connection object may appear in Path or Resv message, and a The Connection TLV may appear in Path or Resv message of co-routed
midpoint that does not support this object is required to pass it on bidirectional LSP.
unaltered, as indicated by the C-Num and the rules defined in
[RFC2205]. 4.3. Global_ID TLV
The Global_ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 associated bidirectional LSP, it can only appear in
the Path message, and will be ignored in the Resv message.
5. IANA Considerations 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 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 7. Acknowledgement
This document was prepared based on the discussion with George This document was prepared based on the discussion with George
Swallow, valuable comments and input was also received from Swallow, valuable comments and input were also received from Berger
Venkatesan Mahalingam and Muliu Tao. Lou, Venkatesan Mahalingam, Jaihari Kalijanakiraman and Muliu Tao.
8. References 8. References
8.1. Normative references 8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
skipping to change at page 6, line 17 skipping to change at page 7, line 48
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 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 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] [I-D.ietf-mpls-tp-cc-cv-rdi]
Allan, D., Swallow, G., and J. Drake, "Proactive Allan, D., Swallow, G., and J. Drake, "Proactive
Connectivity Verification, Continuity Check and Remote Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile", Defect indication for MPLS Transport Profile",
draft-ietf-mpls-tp-cc-cv-rdi-06 (work in progress), draft-ietf-mpls-tp-cc-cv-rdi-06 (work in progress),
August 2011. August 2011.
[I-D.ietf-mpls-tp-identifiers] [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Networks", RFC 5920, July 2010.
Identifiers", draft-ietf-mpls-tp-identifiers-07 (work in
progress), July 2011. [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.
Author's Address Author's Address
Fei Zhang Fei Zhang
ZTE Corporation ZTE Corporation
Email: zhang.fei3@zte.com.cn Email: zhang.fei3@zte.com.cn
Xiao Bao Xiao Bao
ZTE Corporation ZTE Corporation
 End of changes. 29 change blocks. 
92 lines changed or deleted 180 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/