--- 1/draft-ietf-mpls-tp-itu-t-identifiers-04.txt 2012-10-18 22:14:17.261425796 +0200 +++ 2/draft-ietf-mpls-tp-itu-t-identifiers-05.txt 2012-10-18 22:14:17.289425750 +0200 @@ -1,23 +1,23 @@ Network Working Group R. Winter, Ed. Internet-Draft NEC Intended status: Standards Track E. Gray, Ed. -Expires: March 2, 2013 Ericsson +Expires: April 20, 2013 Ericsson H. van Helvoort Huawei Technologies Co., Ltd. M. Betts ZTE - August 29, 2012 + October 17, 2012 MPLS-TP Identifiers Following ITU-T Conventions - draft-ietf-mpls-tp-itu-t-identifiers-04 + draft-ietf-mpls-tp-itu-t-identifiers-05 Abstract This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. @@ -29,21 +29,21 @@ 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." - This Internet-Draft will expire on March 2, 2013. + This Internet-Draft will expire on April 20, 2013. Copyright Notice Copyright (c) 2012 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 @@ -77,21 +77,21 @@ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document augments the initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP) - specified in [RFC6370]. + defined in [RFC6370]. [RFC6370] defines a set of MPLS-TP transport and management entity identifiers to support bidirectional (co-routed and associated) point-to-point MPLS-TP LSPs, including PWs and Sections which follow the IP/MPLS conventions. This document specifies an alternative way to uniquely identify an operator/service provider based on ITU-T conventions and specifies how this operator/service provider identifier can be used to make the existing set of MPLS-TP transport and management entity identifiers, @@ -304,21 +304,21 @@ 5.2. MPLS-TP LSP Identifiers The following sub-sections define identifiers for MPLS-TP co-routed bidirectional and associated bidirectional LSPs. Since MPLS-TP Sub- Path Maintenance Entities (SPMEs) are also LSPs, they use the same form of IDs. 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers The LSP identifier (LSP_ID) for a co-routed bidirectional LSP is - formed by adding a 16-bit unsigend integer LSP number (LSP_Num) to + formed by adding a 16-bit unsigned integer LSP number (LSP_Num) to the tunnel ID. Consequently, the format of an MPLS-TP co-routed bidirectional LSP_ID is: A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num [RFC6370] notes that, the "uniqueness of identifiers does not depend on the A1/Z9 sort ordering". A co-routed bidirectional LSP is provisioned or signaled as a single entity and therefore a single LSP_Num is used for both unidirectional @@ -411,45 +411,44 @@ components by a receiver. The UMC MUST be unique within the organization identified by the combination of CC and ICC. The ICC_Operator_ID-based MEG_ID may be applied equally to a single MPLS-TP Section, LSP or Pseudowire. 7.2. MEP Identifiers - ICC_Operator_ID-based MEP_IDs for MPLS-TP LSPs and Pseudowires are - formed by appending a 32-bit index to the MEG_ID defined in - Section 7.1 above. Within the context of a particular MEG, we call - the identifier associated with a MEP the MEP Index (MEP_Index). The - MEP_Index is administratively assigned. It is encoded as a 32-bit - unsigned integer and MUST be unique within the MEG. An - ICC_Operator_ID-based MEP_ID is structured as: + ICC_Operator_ID-based MEP_IDs for MPLS-TP Sections, LSPs and + Pseudowires are formed by appending a 16-bit index to the MEG_ID + defined in Section 7.1 above. Within the context of a particular + MEG, we call the identifier associated with a MEP the MEP Index + (MEP_Index). The MEP_Index is administratively assigned. It is + encoded as a 16-bit unsigned integer and MUST be unique within the + MEG. An ICC_Operator_ID-based MEP_ID is structured as: MEG_ID::MEP_Index An ICC_Operator_ID-based MEP ID is globally unique by construction given the ICC_Operator_ID-based MEG_ID's global uniqueness. 7.3. MIP Identifiers - ICC_Operator_ID-based MIP_IDs are formed the same way MEP_IDs are - constructed, i.e. by appending a 32-bit MIP Index (MIP_Index) to the - MEG_ID. The MIP_Index is administratively assigned and encoded as a - 32-bit unsigned integer. It MUST be unique within the MEG. An - ICC_Operator_ID-based MIP_ID is structured as: - - MEG_ID::MIP_Index + ICC_Operator_ID-based MIP_IDs for MPLS-TP Sections, LSPs and + Pseudowires are formed by a global IF_ID that is obtained by + prefixing the identifier of the interface the MIP resides with the + ICC_Operator_ID as described in Section 3.1. This allows MIPs to be + independently identified in nodes where a per-interface MIP model is + used. - An ICC_Operator_ID-based MIP ID is globally unique by construction - given the ICC_Operator_ID-based MEG_ID's global uniqueness. + If only a per-node MIP model is used, one MIP is configured. In this + case, the MIP_ID is formed by using the Node_ID and an IF_Num of 0. 8. Security Considerations This document extends an existing information model and does not introduce new security concerns. But, as mentioned in the security considerations section of [RFC6370] protocol specifications that describe use of this information model may introduce security risks and concerns about authentication of participants. For this reason, these protocol specifications need to describe security and authentication concerns that may be raised by the particular @@ -470,35 +469,35 @@ [M1400] "Designations for interconnections among operators' networks", ITU-T Recommendation M.1400, July 2006, . [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. - [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and - Maintenance Framework for MPLS-Based Transport Networks", - RFC 6371, September 2011. - [Y.1731_cor1] "OAM functions and mechanisms for Ethernet based networks - Corrigendum 1", ITU-T Recommendation ITU-T G.8013/Y.1731 (2011) Corrigendum 1. 10.2. Informative References [ICC-list] "List of ITU Carrier Codes (ICCs)", . + [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and + Maintenance Framework for MPLS-Based Transport Networks", + RFC 6371, September 2011. + Authors' Addresses Rolf Winter (editor) NEC Email: rolf.winter@neclab.eu Eric Gray (editor) Ericsson Email: eric.gray@ericsson.com