idnits 2.17.1 draft-chen-ccamp-mpls-tp-oio-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4562 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3473' is defined on line 262, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-mpls-tp-itu-t-identifiers-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen 3 Internet-Draft L. Zheng 4 Intended status: Standards Track Huawei Technologies Co., Ltd 5 Expires: May 3, 2012 October 31, 2011 7 Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operator 8 Identifier Object 9 draft-chen-ccamp-mpls-tp-oio-01.txt 11 Abstract 13 Two formats of operator identifier are specified in Multi-Protocol 14 Label Switching Transport Profile (MPLS-TP) networks, to uniquely 15 identify an operator. One is Global_ID, the other is 16 ICC_Operator_ID. In MPLS-TP networks, operator identifier as part of 17 the global identifier of an MPLS-TP LSP may be required to be carried 18 in the Path/Resv message when setting up the LSP. 20 This document defines a new RSVP-TE Object: Operator Identifier 21 object (OIO). It has two types, the Global_ID object and the 22 ICC_Operator_ID object. Similar as Session and Sender Template 23 object, OIO could be carried in the Path or Resv message to 24 communicate the Operator ID that the two ends of an LSP in use. At 25 the same time, it makes sure all the nodes that the LSP traverses to 26 use the same format of Operator ID. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 3, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Operator Identifier Object . . . . . . . . . . . . . . . . . . 4 69 2.1. Global_ID Object . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. ICC_Operator_ID Object . . . . . . . . . . . . . . . . . . 5 71 2.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 RFC6370 [RFC6370] specifies an initial set of identifiers to be used 83 in the Multiprotocol Label Switching Transport Profile (MPLS-TP). 84 The Global_ID is defined in RFC6370 [RFC6370] to uniquely identify an 85 operator. [I.D.draft-ietf-mpls-tp-itu-t-identifiers] 86 [I-D.ietf-mpls-tp-itu-t-identifiers] specifies the ICC_Operator_ID, 87 an alternative way to uniquely identify an operator based on ITU-T 88 conventions. We call both Global_ID and ICC_Operator_ID as Operator 89 ID in this document. The Operator ID is used to provide a globally 90 unique context for other MPLS-TP identifiers. 92 Resource ReserVation Protocol Traffic Engineering (RSVP-TE) signaling 93 [RFC3209][RFC3471] does not exchange Operator ID when setup an LSP. 94 It is because in the traditional MPLS network the use of Operator ID 95 is not necessary. When the IP addresses is globally unique, a 96 Traffic Engineering (TE) LSP could be uniquely identified by the 97 source IP address, destination IP address, Tunnel ID and Label 98 Switching Path (LSP) ID of the LSP, which are carried in the Session 99 and Sender Template/Filter Spec object. But in MPLS-TP networks, the 100 Node Identifier (Node_ID) is unique within the scope of the Operator 101 ID. In situations where a Node_ID needs to be globally unique, this 102 is accomplished by prefixing the identifier with the Operator ID. 103 This means the Operator ID as part of the global identifier of an 104 MPLS-TP LSP may be required to be carried in the Path/Resv message 105 when setting up the LSP. 107 In addition, since two formats of Operator ID are defined, 108 i.e.Global_ID and ICC_Operator_ID, two things need to be determined 109 when setting up a LSP in terms of Operator ID. One is that which 110 format should be used, the other is that how to make sure both ends 111 of the LSP using the same format. The former could be achieved by 112 the configuration of the operators. The later may need some 113 signaling exchange. 115 This document defines a new RSVP-TE object: Operator Identifier 116 object (OIO). It has two types, the Global_ID object and 117 ICC_Operator_ID object. Similar as the Session and Sender Template/ 118 Filter Spec object, OIO could be carried in the Path/Resv message to 119 communicate the Operator ID that the two ends of an LSP in use. At 120 the same time, it makes sure all the nodes that the LSP traverses to 121 use the same format of Operator ID. 123 2. Operator Identifier Object 125 Two types of Operator Identifier object (OIO) are defined in this 126 document for two formats of Operator ID respectively: Global_ID 127 object and ICC_Operator_ID object. Both Global_ID and 128 ICC_Operator_ID object are OPTIONAL. When setting up an MPLS-TP LSP, 129 one and only one type of the OIO MUST be included in the Path/Resv 130 message if the Operator ID is required. 132 2.1. Global_ID Object 134 The encoding of the Global_ID object including the common object 135 header is as follows: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Length | Class-Num (TBA)| C-Type (1) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Global_ID | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure 1. Global_ID Object 146 Class-Num: To be allocated by IANA. 148 C-Type: To be allocated by IANA (0x01 is recommended). 150 Global_ID: Global_ID of the sender node. As defined in RFC6370 151 [RFC6370], a Global_ID is an unsigned 32-bit value and MUST be 152 derived from a 4-octet AS number assigned to the operator. Note that 153 2-octet AS numbers have been incorporated in the 4-octet by placing 154 the 2-octet AS number in the low-order octets and setting the two 155 high-order octets to zero. 157 2.2. ICC_Operator_ID Object 159 The encoding of the ICC_Operator_ID object including the common 160 object header is as follows: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Length | Class-Num (TBA)| C-Type (2) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | ICC_Operator_ID | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | ICC_Operator_ID(contd.) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 2. ICC_Operator_ID Object 172 Class-Num: To be allocated by IANA. 174 C-Type: To be allocated by IANA (0x02 is recommended). 176 ICC_Operator_ID: ICC_Operator_ID of the sender node. As defined in 177 [I-D.ietf-mpls-tp-itu-t-identifiers], the ICC_Operator_ID is formed 178 by Country Code (CC) and ICC(ITU-T Carrier Code ) as CC::ICC. The 179 ICC itself is a string of one to six characters, global uniqueness is 180 assured by concatenating the ICC with a CC. The Country Code 181 (alpha-2) is a string of two alphabetic characters represented with 182 upper case letters (i.e., A-Z). When the length of a ICC_Operator_ID 183 string is less than 8 octets, the higher-order unused octets of the 184 ICC_Operator_ID field MUST be set to zero. 186 2.3. Procedures 188 When signaling an MPLS-TP LSP, if the Operator ID is needed, e.g. 189 LSRs on the LSP belong to different operators, the Operator 190 Identifier object MUST be carried in the Path message, either the 191 Global_ID or ICC_Operator_ID C-Type is used based on its local 192 configuration. The Global_ID or ICC_Operator_ID field is filled by 193 the sender node's Global_ID or ICC_Operator_ID. When receiving such 194 a Path message with OIO object, the node MUST check it's C-Type to 195 see whether it agree to use that format of Operator ID. If the node 196 agrees, it MUST use the same format of Operator ID. The same C-Type 197 of OIO MUST be carried in the Resv message, and the Global_ID or 198 ICC_Operator_ID field is filled by its own Global_ID or 199 ICC_Operator_ID. 201 If the receiving node does not recognize the Operator Identifier 202 object, it sends a PathErr message with the error code "Unknown 203 object class" towards the sender. If the receiving node recognizes 204 the Operator Identifier object but does not recognize or support the 205 C-Type, it sends a PathErr message with the error code "Unknown 206 object C-Type" towards the sender. If the receiving node, for any 207 reason, is not able to use the same C-Type as sender, e.g. due to 208 fault configuration or requested C-Type not enabled, it MUST send a 209 PathErr message with the error code "Wrong Operator Identifier 210 C-Type" to notify the sender (Error Code to be allocated by IANA), 211 and the LSP is not set up. 213 3. IANA Considerations 215 This document request IANA to assign new Class-Num, C-Types as 216 follows: 217 Class-Num Class Name Class Types or C-Types: 218 --------- ------------------- ------------------------ 219 TBD Operator Identifier 0x01(TBD) Global_ID 220 0x02(TBD) ICC_Operator_ID 222 This document also request IANA to assign new Error-Code as follows: 223 Error Code Meaning 224 ---------- ------------------------------- 225 TBD Wrong Operator Identifier C-Type 227 4. Security Considerations 229 When Operator Identifier Object is in use, a form of source- 230 validation checking may be enabled to ensure that the Global_ID or 231 ICC_Operator_ID originated from a legitimate source, especially in 232 the inter-provider case. 234 5. Acknowledgements 236 6. References 238 6.1. Normative References 240 [I-D.ietf-mpls-tp-itu-t-identifiers] 241 Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP 242 Identifiers Following ITU-T Conventions", 243 draft-ietf-mpls-tp-itu-t-identifiers-01 (work in 244 progress), October 2011. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 250 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 252 6.2. Informative References 254 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 255 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 256 Tunnels", RFC 3209, December 2001. 258 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 259 (GMPLS) Signaling Functional Description", RFC 3471, 260 January 2003. 262 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 263 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 264 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 266 Authors' Addresses 268 Mach(Guoyi) Chen 269 Huawei Technologies Co., Ltd 270 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 271 Beijing 100095 272 China 274 Email: mach@huawei.com 276 Lianshu Zheng 277 Huawei Technologies Co., Ltd 278 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 279 Beijing 100095 280 China 282 Email: vero.zheng@huawei.com