draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02.txt   draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03.txt 
MPLS Working Group F. Zhang CCAMP Working Group F. Zhang
Internet-Draft ZTE Corporation Internet-Draft ZTE Corporation
Intended status: Standards Track March 07, 2012 Intended status: Standards Track M. Venkatesan
Expires: September 8, 2012 Expires: December 08, 2012 Dell Inc.
Y. Xu
CATR
June 08, 2012
RSVP-TE Extensions to Exchange MPLS-TP LSP Identifiers RSVP-TE Extensions to Exchange MPLS-TP LSP Tunnnel Numbers
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03
Abstract Abstract
The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370]
specifies an initial set of identifiers, such as local assigned specifies an initial set of identifiers, including the local assigned
tunnel number and Global_ID, which can be used to form Maintenance Z9-Tunnel_Num, which can be used to form Maintenance Entity Point
Entity Point Identifier (MEP_ID). As to some Operation, 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) [RFC6428], source MEP_ID must be inserted in the [RFC6428], source MEP_ID must be inserted in the OAM packets, so that
OAM packets, so that the peer endpoint can compare the received and the peer endpoint can compare the received and expected MEP_IDs to
expected MEP_IDs to judge whether there is a mismatch [RFC6371], judge whether there is a mis-connnectivity defect [RFC6371], which
which means that the two MEP nodes need to pre-store each other's means that the two MEP nodes need to pre-store each other's MEP_IDs.
MEP_IDs.
This document defines the signaling extensions to exchange the Label This document defines the signaling extensions to communicate the
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 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 September 8, 2012. This Internet-Draft will expire on December 08, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 2
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Co-routed Bidirectional LSP . . . . . . . . . . . . . . . . 3 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Associated Bidirectional LSP . . . . . . . . . . . . . . . 4 4.1. Association Type . . . . . . . . . . . . . . . . . . . . . 3
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4.1. Association Type . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative references . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 4
8.1. Normative references . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370]
specifies a initial set of identifiers, such as local assigned tunnel specifies a initial set of identifiers, including the local assigned
number (Tunnel_Num) and Global_ID, which can be used to form Z9-Tunnel_Num, which can be used to form Maintenance Entity Point
Maintenance Entity Point Identifier (MEP_ID). The MPLS-TP LSP_MEP_ID Identifier (MEP_ID). The MPLS-TP LSP_MEP_ID is
is Node_ID::Tunnel_Num::LSP_Num, and in situations where global Node_ID::Tunnel_Num::LSP_Num, and in situations where global
uniqueness is required, this becomes: Global_ID::Node_ID:: uniqueness is required, this becomes:
Tunnel_Num::LSP_Num. In order to realize some Operation, Global_ID::Node_ID::Tunnel_Num::LSP_Num. In order to realize some
Administration and Maintenance (OAM) functions, such as Connectivity Operation, Administration and Maintenance (OAM) functions, such as
Verification (CV) [RFC6428], source MEP-ID MUST be inserted in the Connectivity Verification (CV) [RFC6428], source MEP-ID MUST be
OAM packets, in this way the peer endpoint can compare the received inserted in the OAM packets, in this way the peer endpoint can
and expected MEP-IDs to judge whether there is a mismatch [RFC6371]. compare the received and expected MEP-IDs to judge whether there is a
Hence, the two MEP nodes must pre-store each other's MEP-IDs before mis-connnectivity defect [RFC6371]. Hence, the two MEP nodes must
sending the CV packets. 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 be
more suitable to realize the exchange of MEP_IDs.
Since the LSP identifiers can be carried in an Extended ASSOCIATION When the LSPs are set up by control plane, Resource ReserVation
object, which may also be used in a single session Protocol Traffic Engnieering (RSVP-TE) messages can be used to
[I-D.ietf-ccamp-assoc-ext], it is naturally to define the signaling communicate the Z9-Tunnel_Num to the ingress LSR (Label Switching
extensions of co-routed and associated bidirectional LSP to exchange Router) of a co-routed bidirectional LSP. Since the LSP identifiers
the LSP identifiers based on the Extended ASSOCIATION object. can be carried in an 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 based on the ASSOCIATION object.
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
3.1. Co-routed Bidirectional LSP Consider that LSP1 is initialized at A1 node with an ASSOCIATION
object inserted in Path message. Association Type is set to "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 Identifers", Association ID set to A1-Tunnel_Num, Association Source
set to A1-Node_ID, Global Association Source set to A1-Global_ID, and set to A1-Node_ID. Upon receipt of the Association Object, the egress
the Extended Association ID field is omitted. Upon receipt of the node Z9 checks the Association Type field. If it is "LSP
Extended Association Object, the terminating node Z9 checks the Identifiers" and an Upstream_Label exists in Path message, the
Association Type field. If it is "LSP Identifiers" and an ASSOCIATION object must be carried in the Resv message also.
Upstream_Label exists in Path message, the Extended ASSOCIATION Similarly, Association Type is set to "LSP Identifiers", Association
object must be carried in the Resv message also. Similarly, ID set to Z9-Tunnel_Num, Association Source set to Z9-Node_ID. In
Association Type is set to "LSP Identifiers", Association ID set to this way, the ingress LSR can get the Z9-Tunnel_Num, which may be
Z9-Tunnel_Num, Association Source set to Z9-Node_ID, Global used for identifying a mis-connnectivity defect of the proactive CV
Association Source set to Z9-Global_ID, and the Extended Association OAM function.
ID field is omitted.
3.2. Associated Bidirectional LSP
The document [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]
discusses the provisioning models and signaling procedures of
associated bidirectional LSPs. Consider the example provided there,
when LSP1 and LSP2 are bound together to be an associated
bidirectional LSP 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 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 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.
4. RSVP-TE Extensions 4. RSVP-TE Extensions
4.1. Association Type 4.1. Association Type
Within the current document, a new Association Type is defined in the Within the current document, a new Association Type is defined in the
Extended ASSOCIATION object. 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 Value Type
----- ----- ----- -----
6 (TBD) LSP Identifiers (L) 6 (TBD) LSP Identifiers (L)
See [I-D.ietf-ccamp-assoc-ext] for the definition of other fields and See [I-D.ietf-ccamp-assoc-ext] for the definition of other fields and
values. values.
The rules associated with the processing of the Extended ASSOCIATION The rules associated with the processing of the Extended ASSOCIATION
objects in RSVP message are discussed in [I-D.ietf-ccamp-assoc-ext]. 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 It said that in the absence of Association Type-specific rules for
identifying association, the included Extended ASSOCIATION objects identifying association, the included ASSOCIATION objects MUST be
MUST be identical. Since the Association Type "LSP Identifiers" used identical. Since the Association Type "LSP Identifiers" used here is
here is to carry LSP identifier, there is no need to associate Path to carry LSP identifier, there is no need to associate Path state to
state to Path state or Resv state to Resv state, one specific rule is Path state or Resv state to Resv state, one specific rule is added:
added: when the Association Type is "LSP Identifiers", the Extended when the Association Type is "LSP Identifiers", the ASSOCIATION
ASSOCIATION object can appear in Path or Resv message across sessions object can appear in Path or Resv message across sessions or in a
or in a single session, and the values can be different. single session, and the values can be different.
5. IANA Considerations 5. IANA Considerations
IANA is requested to administer assignment of new values for IANA is requested to administer assignment of new values for
namespace defined in this document and summarized in this section. namespace defined in this document and summarized in this section.
One bit ("LSP Identifers") needs to be allocated in the Association One bit ("LSP Identifers") needs to be allocated in the Association
Type Registry. Type Registry.
6. Security Considerations 6. Security Considerations
A new Association Type is defined in this document, and except this, A new Association Type is defined in this document, and except this,
there are no security issues about the Extended ASSOCIATION object there are no security issues about the Extended ASSOCIATION object
are introduced here. For Association object related security issues, are introduced here. For Association object related security issues,
see the documents [RFC4872], [RFC4873], and see the documents [RFC4872], [RFC4873], and [I-D.ietf-ccamp-assoc-
[I-D.ietf-ccamp-assoc-ext]. ext].
For a more comprehensive discussion on GMPLS security please see the For a more comprehensive discussion on GMPLS security please see the
Security Framework for MPLS and GMPLS Networks [RFC5920]. 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 were also received from Berger Swallow, valuable comments and input were also received from Lou
Lou, Venkatesan Mahalingam, Jaihari Kalijanakiraman, Muliu Tao and Berger, John E Drake, Jaihari Kalijanakiraman, Muliu Tao and Wenjuan
Wenjuan He. He.
8. References 8. References
8.1. Normative references 8.1. Normative references
[I-D.ietf-ccamp-assoc-ext] [I-D.ietf-ccamp-assoc-ext]
Berger, L., Faucheur, F., and A. Narayanan, "RSVP Berger, L., Faucheur, F. and A. Narayanan, "RSVP
Association Object Extensions", Association Object Extensions", Internet-Draft draft-ietf-
draft-ietf-ccamp-assoc-ext-02 (work in progress), ccamp-assoc-ext-03, March 2012.
February 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 [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.
8.2. Informative References 8.2. Informative References
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE [RFC4872] Lang, J.P., Rekhter, Y. and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi- Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
May 2007. 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D. and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007. "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport [RFC6370] Bocci, M., Swallow, G. and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks", Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011. RFC 6371, September 2011.
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive [RFC6428] Allan, D., Swallow Ed. , G. and J. Drake Ed. ,
Connectivity Verification, Continuity Check, and Remote "Proactive Connectivity Verification, Continuity Check,
Defect Indication for the MPLS Transport Profile", and Remote Defect Indication for the MPLS Transport
RFC 6428, November 2011. Profile", RFC 6428, November 2011.
Author's Address Authors' Addresses
Fei Zhang Fei Zhang
ZTE Corporation ZTE Corporation
Email: zhang.fei3@zte.com.cn 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 Xiao Bao
ZTE Corporation ZTE Corporation
Email: bao.xiao1@zte.com.cn Email: bao.xiao1@zte.com.cn
 End of changes. 24 change blocks. 
153 lines changed or deleted 108 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/