Internet DRAFT - draft-chen-ccamp-mpls-tp-oio
draft-chen-ccamp-mpls-tp-oio
Network Working Group M. Chen
Internet-Draft L. Zheng
Intended status: Standards Track Huawei Technologies Co., Ltd
Expires: May 3, 2012 October 31, 2011
Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operator
Identifier Object
draft-chen-ccamp-mpls-tp-oio-01.txt
Abstract
Two formats of operator identifier are specified in Multi-Protocol
Label Switching Transport Profile (MPLS-TP) networks, to uniquely
identify an operator. One is Global_ID, the other is
ICC_Operator_ID. In MPLS-TP networks, operator identifier as part of
the global identifier of an MPLS-TP LSP may be required to be carried
in the Path/Resv message when setting up the LSP.
This document defines a new RSVP-TE Object: Operator Identifier
object (OIO). It has two types, the Global_ID object and the
ICC_Operator_ID object. Similar as Session and Sender Template
object, OIO could be carried in the Path or Resv message to
communicate the Operator ID that the two ends of an LSP in use. At
the same time, it makes sure all the nodes that the LSP traverses to
use the same format of Operator ID.
Requirements Language
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 RFC 2119 [RFC2119].
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."
Chen & Zheng Expires May 3, 2012 [Page 1]
Internet-Draft Operator Identifier Object October 2011
This Internet-Draft will expire on May 3, 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.
Chen & Zheng Expires May 3, 2012 [Page 2]
Internet-Draft Operator Identifier Object October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Operator Identifier Object . . . . . . . . . . . . . . . . . . 4
2.1. Global_ID Object . . . . . . . . . . . . . . . . . . . . . 5
2.2. ICC_Operator_ID Object . . . . . . . . . . . . . . . . . . 5
2.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Chen & Zheng Expires May 3, 2012 [Page 3]
Internet-Draft Operator Identifier Object October 2011
1. Introduction
RFC6370 [RFC6370] specifies an initial set of identifiers to be used
in the Multiprotocol Label Switching Transport Profile (MPLS-TP).
The Global_ID is defined in RFC6370 [RFC6370] to uniquely identify an
operator. [I.D.draft-ietf-mpls-tp-itu-t-identifiers]
[I-D.ietf-mpls-tp-itu-t-identifiers] specifies the ICC_Operator_ID,
an alternative way to uniquely identify an operator based on ITU-T
conventions. We call both Global_ID and ICC_Operator_ID as Operator
ID in this document. The Operator ID is used to provide a globally
unique context for other MPLS-TP identifiers.
Resource ReserVation Protocol Traffic Engineering (RSVP-TE) signaling
[RFC3209][RFC3471] does not exchange Operator ID when setup an LSP.
It is because in the traditional MPLS network the use of Operator ID
is not necessary. When the IP addresses is globally unique, a
Traffic Engineering (TE) LSP could be uniquely identified by the
source IP address, destination IP address, Tunnel ID and Label
Switching Path (LSP) ID of the LSP, which are carried in the Session
and Sender Template/Filter Spec object. But in MPLS-TP networks, the
Node Identifier (Node_ID) is unique within the scope of the Operator
ID. In situations where a Node_ID needs to be globally unique, this
is accomplished by prefixing the identifier with the Operator ID.
This means the Operator ID as part of the global identifier of an
MPLS-TP LSP may be required to be carried in the Path/Resv message
when setting up the LSP.
In addition, since two formats of Operator ID are defined,
i.e.Global_ID and ICC_Operator_ID, two things need to be determined
when setting up a LSP in terms of Operator ID. One is that which
format should be used, the other is that how to make sure both ends
of the LSP using the same format. The former could be achieved by
the configuration of the operators. The later may need some
signaling exchange.
This document defines a new RSVP-TE object: Operator Identifier
object (OIO). It has two types, the Global_ID object and
ICC_Operator_ID object. Similar as the Session and Sender Template/
Filter Spec object, OIO could be carried in the Path/Resv message to
communicate the Operator ID that the two ends of an LSP in use. At
the same time, it makes sure all the nodes that the LSP traverses to
use the same format of Operator ID.
2. Operator Identifier Object
Two types of Operator Identifier object (OIO) are defined in this
document for two formats of Operator ID respectively: Global_ID
Chen & Zheng Expires May 3, 2012 [Page 4]
Internet-Draft Operator Identifier Object October 2011
object and ICC_Operator_ID object. Both Global_ID and
ICC_Operator_ID object are OPTIONAL. When setting up an MPLS-TP LSP,
one and only one type of the OIO MUST be included in the Path/Resv
message if the Operator ID is required.
2.1. Global_ID Object
The encoding of the Global_ID object including the common object
header is as follows:
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 | Class-Num (TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Global_ID Object
Class-Num: To be allocated by IANA.
C-Type: To be allocated by IANA (0x01 is recommended).
Global_ID: Global_ID of the sender node. As defined in RFC6370
[RFC6370], a Global_ID is an unsigned 32-bit value and MUST be
derived from a 4-octet AS number assigned to the operator. Note that
2-octet AS numbers have been incorporated in the 4-octet by placing
the 2-octet AS number in the low-order octets and setting the two
high-order octets to zero.
2.2. ICC_Operator_ID Object
The encoding of the ICC_Operator_ID object including the common
object header is as follows:
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 | Class-Num (TBA)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC_Operator_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC_Operator_ID(contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. ICC_Operator_ID Object
Class-Num: To be allocated by IANA.
C-Type: To be allocated by IANA (0x02 is recommended).
Chen & Zheng Expires May 3, 2012 [Page 5]
Internet-Draft Operator Identifier Object October 2011
ICC_Operator_ID: ICC_Operator_ID of the sender node. As defined in
[I-D.ietf-mpls-tp-itu-t-identifiers], the ICC_Operator_ID is formed
by Country Code (CC) and ICC(ITU-T Carrier Code ) as CC::ICC. The
ICC itself is a string of one to six characters, global uniqueness is
assured by concatenating the ICC with a CC. The Country Code
(alpha-2) is a string of two alphabetic characters represented with
upper case letters (i.e., A-Z). When the length of a ICC_Operator_ID
string is less than 8 octets, the higher-order unused octets of the
ICC_Operator_ID field MUST be set to zero.
2.3. Procedures
When signaling an MPLS-TP LSP, if the Operator ID is needed, e.g.
LSRs on the LSP belong to different operators, the Operator
Identifier object MUST be carried in the Path message, either the
Global_ID or ICC_Operator_ID C-Type is used based on its local
configuration. The Global_ID or ICC_Operator_ID field is filled by
the sender node's Global_ID or ICC_Operator_ID. When receiving such
a Path message with OIO object, the node MUST check it's C-Type to
see whether it agree to use that format of Operator ID. If the node
agrees, it MUST use the same format of Operator ID. The same C-Type
of OIO MUST be carried in the Resv message, and the Global_ID or
ICC_Operator_ID field is filled by its own Global_ID or
ICC_Operator_ID.
If the receiving node does not recognize the Operator Identifier
object, it sends a PathErr message with the error code "Unknown
object class" towards the sender. If the receiving node recognizes
the Operator Identifier object but does not recognize or support the
C-Type, it sends a PathErr message with the error code "Unknown
object C-Type" towards the sender. If the receiving node, for any
reason, is not able to use the same C-Type as sender, e.g. due to
fault configuration or requested C-Type not enabled, it MUST send a
PathErr message with the error code "Wrong Operator Identifier
C-Type" to notify the sender (Error Code to be allocated by IANA),
and the LSP is not set up.
3. IANA Considerations
This document request IANA to assign new Class-Num, C-Types as
follows:
Class-Num Class Name Class Types or C-Types:
--------- ------------------- ------------------------
TBD Operator Identifier 0x01(TBD) Global_ID
0x02(TBD) ICC_Operator_ID
Chen & Zheng Expires May 3, 2012 [Page 6]
Internet-Draft Operator Identifier Object October 2011
This document also request IANA to assign new Error-Code as follows:
Error Code Meaning
---------- -------------------------------
TBD Wrong Operator Identifier C-Type
4. Security Considerations
When Operator Identifier Object is in use, a form of source-
validation checking may be enabled to ensure that the Global_ID or
ICC_Operator_ID originated from a legitimate source, especially in
the inter-provider case.
5. Acknowledgements
6. References
6.1. Normative References
[I-D.ietf-mpls-tp-itu-t-identifiers]
Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP
Identifiers Following ITU-T Conventions",
draft-ietf-mpls-tp-itu-t-identifiers-01 (work in
progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
6.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
Chen & Zheng Expires May 3, 2012 [Page 7]
Internet-Draft Operator Identifier Object October 2011
Authors' Addresses
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd
Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
Beijing 100095
China
Email: mach@huawei.com
Lianshu Zheng
Huawei Technologies Co., Ltd
Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
Beijing 100095
China
Email: vero.zheng@huawei.com
Chen & Zheng Expires May 3, 2012 [Page 8]
