--- 1/draft-berger-ccamp-swcaps-update-01.txt 2012-10-15 16:53:13.957460372 +0200 +++ 2/draft-berger-ccamp-swcaps-update-02.txt 2012-10-15 16:53:13.973712493 +0200 @@ -1,20 +1,20 @@ Internet Draft Lou Berger (LabN) Updates: 3471, 4202, 4203, 5307 Julien Meuric (France Telecom) Category: Standards Track -Expiration Date: November 20, 2012 +Expiration Date: January 4, 2013 - May 20, 2012 + July 4, 2012 Revised Definition of The GMPLS Switching Capability and Type Fields - draft-berger-ccamp-swcaps-update-01.txt + draft-berger-ccamp-swcaps-update-02.txt Abstract GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values using in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are @@ -40,21 +40,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on November 20, 2012 + This Internet-Draft will expire on January 4, 2013 Copyright and License 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 @@ -122,28 +122,21 @@ technology certainly fits the design objectives of GMPLS, the definition of multiple PSC Switching Types has also proven to be of little value. Notably, there are no known uses of PSC-2, PSC-3 and PSC-4. This document proposes to resolve such inconsistent definitions and uses of the Switching Types by reducing the scope of the related fields and narrowing their use. In particular this document proposes deprecating the use of the Switching Types as an identifier of hierarchy levels within a switching technology, and limit its use to - identification of a per-switching technology SCSI field format. This - document also defines, for routing, a generic method for identifying - a hierarchy levels within a switching technology. - - An alternate approach, which is not advocated by this document, is to - ensure that Switching Types are assigned for all hierarchy levels - within a switching technology as part of any new work, e.g., as part - of [GMPLS-G709]. + identification of a per-switching technology SCSI field format. This document updates any document that uses the GMPLS Switching Capability and Switching Type fields, in particular RFCs 3471, 4202, 4203, and 5307. 1.1. Current Switching Type Definition The Switching Type values are carried in both routing and signaling. Values are identified in the IANA GMPLS Signaling Parameters Switching Type registry, which is currently located at @@ -250,124 +243,105 @@ This document deprecates the following Switching Types: Value Name 2 Packet-Switch Capable-2 (PSC-2) 3 Packet-Switch Capable-3 (PSC-3) 4 Packet-Switch Capable-4 (PSC-4) These values SHOULD NOT be treated as reserved values, i.e., SHOULD NOT be generated and SHOULD be ignored upon receipt. -3. Intra-Technology Hierarchy - - [Authors note: This section is for discussion and may be dropped. - Particularly, need to revisit MLN/IACD/XRO implications to ensure - there are no gating issues.] - - Multiple switching technologies support forms of hierarchical - switching within a particular data plane technology. As discussed - above, GMPLS routing originally envisioned support for such cases for - packet networks using PSC-2, 3, 4. In other cases, GMPLS defined - support using technology specific mechanisms, for example Signal Type - was defined for SONET/SDH, see [RFC4606]. Given that one of the - objectives of GMPLS is to generalize control plane protocols, it is - reasonable to define a method for supporting hierarchical switching - within a particular data plane technology that is not specific to any - particular technology. This section defines such a mechanism for - routing. No additional mechanism is defined for signaling. - - In order to support hierarchical switching within a particular data - plane technology in routing, this section defines the Intra- - Technology Hierarchy, or ITH, field. This field allows for - representation of up to 15 levels of hierarchical switching. It, for - example, can represent the bottom most level of a multiplexing - hierarchy. The ITH field is carried in a portion of the previously - defined reserved field of the Interface Switching Capability - Descriptor and has the following format: - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Switching Cap | Encoding | Reserved | ITH | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - For compatibility reasons, an ITH value of 0 indicates that the ITH - field is not being used. The mapping of ITH values to specific - levels of hierarchy within a data plane technology is specific to - each switching technology and is therefore outside the scope of this - document. - -4. Compatibility - - This document has two impacts on existing implementations. Both - routing and signaling impacts must be considered. +3. Compatibility - For existing implementations, the primary impact is deprecating the - use of PSC-2, 3 and 4. At the time of publication of this document, + For existing implementations, the primary impact of this document is + deprecating the use of PSC-2, 3 and 4. At the time of publication, there are no known deployments (or even implementations) that make use of these values so there is no compatibility issues for current routing and signaling implementations. - A secondary impact is the use of the previously reserved field of the - routing Interface Switching Capability Descriptor. For existing - routing implementations, this field should be set to all zeros when - generating a Descriptor, and should be ignored on receipt. - Furthermore, existing nodes are expected to propagate reserved fields - without any modification. Therefore the use of this reserved field - is not considered to result in any compatibility issues in routing. - As this field is not used in signaling, there are no signaling - compatibility issues. - -5. Security Considerations +4. Security Considerations This document impacts the values carried in a single field in signaling and routing. As no new protocol formats or mechanisms are defined, there are no particular security implications raised by this document. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. -6. IANA Considerations +5. IANA Considerations - IANA needs to deprecate and redefine the registry. + IANA needs to deprecate and redefine the registry. In particular the + Switching Types portion of the Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Parameters should be revised to read: -7. Acknowledgments + Switching Types + + Registration Procedures + + Standards Action + + Reference + [RFC3471][RFC4328][This.draft] + + Value Name Reference + 0 Unassigned + 1 Packet-Switch Capable-1 (PSC-1) [RFC3471] + 2 Deprecated [This.draft] + 3 Deprecated [This.draft] + 4 Deprecated [This.draft] + 5-29 Unassigned + 30 Ethernet Virtual Private Line (EVPL) [RFC6004] + 31-39 Unassigned + 40 802_1 PBB-TE [RFC6060] + 41-50 Unassigned + 51 Layer-2 Switch Capable (L2SC) [RFC3471] + 52-99 Unassigned + 100 Time-Division-Multiplex Capable (TDM) [RFC3471] + 101-124 Unassigned + 125 Data Channel Switching Capable (DCSC) [RFC6002] + 126-149 Unassigned + 150 Lambda-Switch Capable (LSC) [RFC3471] + 151-199 Unassigned + 200 Fiber-Switch Capable (FSC) [RFC3471] + 201-255 Unassigned + +6. Acknowledgments We thank John Drake for highlighting the current inconsistent definitions associated with the Switching Capability and Type Fields. Daniele Ceccarelli provided valuable feedback on this document. -8. References +7. References -8.1. Normative References +7.1. Normative References [RFC2119] Bradner, S., "RFC Key Words Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K., Rekhter, Y., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5307] Kompella, K., Rekhter, Y., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. -8.2. Informative References +7.2. Informative References [G.707] ITU-T Recommendation G.707/Y.1322 (2007), "Network node interface for the synchronous digital hierarchy (SDH)". [G.709] ITU-T Recommendation G.709/Y.1331 (2009), "Interfaces for the Optical Transport Network (OTN)". [GMPLS-G709] Zhang, F., Li, D., Li, H., Belotti, S., Ceccarelli, D., "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", work in progress, @@ -399,26 +373,25 @@ [RFC6004] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching", RFC 6004, front 2010. [RFC6060] Fedyk, D., Shah, H., Bitar, N., Takacs, A., "Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)", RFC 6060, March 2011. -9. Authors' Addresses +8. Authors' Addresses Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net - Julien Meuric France Telecom Research & Development 2, avenue Pierre Marzin 22307 Lannion Cedex - France Phone: +33 2 96 05 28 28 Email: julien.meuric@orange-ftgroup.com -Generated on: Fri, May 18, 2012 5:29:08 PM +Generated on: Wed, Jul 04, 2012 12:19:48 PM