draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03.txt   draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt 
CCAMP Working Group F. Zhang CCAMP Working Group F. Zhang
Internet-Draft ZTE Corporation Internet-Draft ZTE Corporation
Intended status: Standards Track M. Venkatesan Intended status: Standards Track M. Venkatesan
Expires: December 08, 2012 Dell Inc. Expires: February 17, 2013 Dell Inc.
Y. Xu Y. Xu
CATR CATR
June 08, 2012 R. Gandhi
Cisco Systems
August 16, 2012
RSVP-TE Extensions to Exchange MPLS-TP LSP Tunnnel Numbers RSVP-TE Extensions to Exchange MPLS-TP LSP Tunnel Numbers
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03 draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04
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, including the local assigned specifies an initial set of identifiers, including the local assigned
Z9-Tunnel_Num, which can be used to form Maintenance Entity Point Z9-Tunnel_Num, which can be used to form Maintenance Entity Point
Identifier (MEP_ID). As to some Operation, Administration and Identifier (MEP_ID). As to some Operation, Administration and
Maintenance (OAM) functions, such as Connectivity Verification (CV) Maintenance (OAM) functions, such as Connectivity Verification (CV)
[RFC6428], source MEP_ID must be inserted in the OAM packets, so that [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 the peer endpoint can compare the received and expected MEP_IDs to
judge whether there is a mis-connnectivity defect [RFC6371], which judge whether there is a mis-connectivity defect [RFC6371], which
means that the two MEP nodes need to pre-store each other's MEP_IDs. means that the two MEP nodes need to pre-store each other's MEP_IDs.
This document defines the signaling extensions to communicate the This document defines the signaling extensions to communicate the
local assigned Z9-Tunnel_Num to the ingress LSR (Label Switching local assigned Z9-Tunnel_Num to the ingress LSR (Label Switching
Router) of a co-routed bidirectional LSP. 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.
skipping to change at page 1, line 45 skipping to change at page 1, line 47
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 December 08, 2012. This Internet-Draft will expire on February 17, 2013.
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 (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 3 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Association Type . . . . . . . . . . . . . . . . . . . . . 3 4.1. Association Type . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4.2. Signaling Procedure . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative references . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 4 8.1. Normative references . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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, including the local assigned specifies a initial set of identifiers, including the local assigned
Z9-Tunnel_Num, which can be used to form Maintenance Entity Point Z9-Tunnel_Num, which can be used to form Maintenance Entity Point
Identifier (MEP_ID). The MPLS-TP LSP_MEP_ID is Identifier (MEP_ID). The MPLS-TP LSP_MEP_ID is Node_ID::Tunnel_Num::
Node_ID::Tunnel_Num::LSP_Num, and in situations where global LSP_Num, and in situations where global uniqueness is required, this
uniqueness is required, this becomes: becomes: Global_ID::Node_ID::Tunnel_Num::LSP_Num. In order to realize
Global_ID::Node_ID::Tunnel_Num::LSP_Num. In order to realize some some Operation, Administration and Maintenance (OAM) functions, such
Operation, Administration and Maintenance (OAM) functions, such as as Connectivity Verification (CV) [RFC6428], source MEP-ID MUST be
Connectivity Verification (CV) [RFC6428], 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
mis-connnectivity defect [RFC6371]. Hence, the two MEP nodes must mis-connectivity defect [RFC6371]. Hence, the two MEP nodes must
pre-store each other's MEP-IDs before sending the CV packets. pre-store each other's MEP-IDs before sending the CV packets.
When the LSPs are set up by control plane, Resource ReserVation When the LSPs are set up by control plane, Resource ReserVation
Protocol Traffic Engnieering (RSVP-TE) messages can be used to Protocol Traffic Engineering (RSVP-TE) messages can be used to
communicate the Z9-Tunnel_Num to the ingress LSR (Label Switching communicate the Z9-Tunnel_Num to the ingress LSR (Label Switching
Router) of a co-routed bidirectional LSP. Since the LSP identifiers Router) of a co-routed bidirectional LSP. Since the LSP identifiers
can be carried in an ASSOCIATION object, which may also be used in a can be carried in an ASSOCIATION object [I-D.ietf-ccamp-assoc-ext],
single session [I-D.ietf-ccamp-assoc-ext], it is naturally to define it is naturally to define the signaling extensions based on the
the signaling extensions based on the ASSOCIATION object. 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
Consider that LSP1 is initialized at A1 node with an ASSOCIATION Consider that LSP1 is initialized at A1 node with an ASSOCIATION
object inserted in Path message. Association Type is set to "LSP object inserted in Path message. Association Type is set to "LSP
Identifers", Association ID set to A1-Tunnel_Num, Association Source Identifiers", Association ID set to A1-Tunnel_Num, Association Source
set to A1-Node_ID. Upon receipt of the Association Object, the egress set to A1-Node_ID. Upon receipt of the Association Object, the
node Z9 checks the Association Type field. If it is "LSP egress node Z9 checks the Association Type field. If it is "LSP
Identifiers" and an Upstream_Label exists in Path message, the Identifiers", the ASSOCIATION object must be carried in the Resv
ASSOCIATION object must be carried in the Resv message also. message also. Similarly, Association Type is set to "LSP
Similarly, Association Type is set to "LSP Identifiers", Association Identifiers", Association ID set to Z9-Tunnel_Num, Association Source
ID set to Z9-Tunnel_Num, Association Source set to Z9-Node_ID. In set to Z9-Node_ID. In this way, the ingress LSR can get the Z9-
this way, the ingress LSR can get the Z9-Tunnel_Num, which may be Tunnel_Num, which may be used for identifying a mis-connectivity
used for identifying a mis-connnectivity defect of the proactive CV defect of the proactive CV OAM function.
OAM function.
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.
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
ASSOCIATION object, which MAY be used with any ASSOCIATION object ASSOCIATION object, which MAY be used with any ASSOCIATION object
type. For example, the Extended ASSOCIATION object defined in [I-D type. For example, the Extended ASSOCIATION object defined in
.ietf-ccamp-assoc-ext] can be used when Global ID based [I-D.ietf-ccamp-assoc-ext] can be used when Global_ID based
identification is desired. identification is desired.
Value Type Value Type
----- ----- ----- -----
6 (TBD) LSP Identifiers (L) 5 (TBD) LSP Identifiers (L)
See [I-D.ietf-ccamp-assoc-ext] for the definition of other fields and 4.2. Signaling Procedure
values.
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.
For Resv message, Global Association Source is the Global_ID of
the node sending out the Resv message.
Extended Association ID:
Same as defined in [I-D.ietf-ccamp-assoc-ext] if Extended
ASSOCIATION object is used.
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 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 ASSOCIATION objects MUST be identifying association, the included ASSOCIATION objects MUST be
identical. Since the Association Type "LSP Identifiers" used here is identical. Since the Association Type "LSP Identifiers" used here is
to carry LSP identifier, there is no need to associate Path state to 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: Path state or Resv state to Resv state, one specific rule is added:
when the Association Type is "LSP Identifiers", the ASSOCIATION when the Association Type is "LSP Identifiers", the ASSOCIATION
object can appear in Path or Resv message across sessions or in a object can appear in Path or Resv message across sessions 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 value ("LSP Identifiers") needs to be allocated in the
Type Registry. Association 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 ASSOCIATION object and
are introduced here. For Association object related security issues, Extended ASSOCIATION object are introduced here. For Association
see the documents [RFC4872], [RFC4873], and [I-D.ietf-ccamp-assoc- object related security issues, see the documents [RFC4872],
ext]. [RFC4873], and [I-D.ietf-ccamp-assoc-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 Lou Swallow, valuable comments and input were also received from Lou
Berger, John E Drake, Jaihari Kalijanakiraman, Muliu Tao and Wenjuan Berger, John E Drake, Jaihari Kalijanakiraman, Muliu Tao and 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", Internet-Draft draft-ietf- Association Object Extensions",
ccamp-assoc-ext-03, March 2012. draft-ietf-ccamp-assoc-ext-04 (work in progress),
August 2012.
[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.P., Rekhter, Y. and D. Papadimitriou, "RSVP-TE [RFC4872] Lang, J., 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, May Protocol Label Switching (GMPLS) Recovery", RFC 4872,
2007. May 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. , [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
"Proactive Connectivity Verification, Continuity Check, Connectivity Verification, Continuity Check, and Remote
and Remote Defect Indication for the MPLS Transport Defect Indication for the MPLS Transport Profile",
Profile", RFC 6428, November 2011. RFC 6428, November 2011.
Authors' Addresses Authors' Addresses
Fei Zhang Fei Zhang
ZTE Corporation ZTE Corporation
Email: zhang.fei3@zte.com.cn Email: zhang.fei3@zte.com.cn
Venkatesan Mahalingam Venkatesan Mahalingam
Dell Inc. Dell Inc.
Email: venkat.mahalingams@gmail.com Email: venkat.mahalingams@gmail.com
Yunbin Xu Yunbin Xu
CATR CATR
Email: xuyunbin@mail.ritt.com.cn Email: xuyunbin@mail.ritt.com.cn
Rakesh Gandhi
Cisco Systems
Email: rgandhi@cisco.com
Xiao Bao Xiao Bao
ZTE Corporation ZTE Corporation
Email: bao.xiao1@zte.com.cn Email: bao.xiao1@zte.com.cn
 End of changes. 26 change blocks. 
67 lines changed or deleted 117 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/