Internet Engineering Task Force A. Davey INTERNET-DRAFT N. Neate Updates: RFC3471 Data Connection Ltd (DCL) Expires: August 2005 February 2005 Generalized Multi-Protocol Label Switching (GMPLS) Control Channel Separation with an IPv6 Control Plane <draft-davey-ccamp-gmpls-ipv6-if-index-00.txt> Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." 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 Copyright Notice Copyright (C) The Internet Society 2005. All Rights Reserved. Abstract This document specifies extensions to GMPLS signalling with control channel separation, [RFC3471], to use 128-bit IPv6 addresses to identify routers in an IPv6 control plane. Davey and Neate Internet Draft [Page 1]
Internet Draft IPv6 Control Channel Separation February 2005 1. Terms 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. 2. Overview Currently, GMPLS signalling with control channel separation identifies the particular data channel being controlled by providing interface identification information TLVs [RFC3471]. For unnumbered and component interfaces, interface indentification is achieved through the tuple of a 32-bit IP address and an interface ID. The IP address field may carry either an IP address of a link or an IP address associated with the router, where associated address is the value carried in a router address TLV of routing. An IPv6 address of a link is clearly 128-bits. Also, drafts to define traffic engineering extensions to IGP protocols for use in IPv6 networks use 128-bit router addresses: see definition of "Router IPv6 Address" in [OSPFv3-TE] and "IPv6 TE Router ID" in [ISIS-TE]. This document proposes a simple extension to [RFC3471] that allows GMPLS signalling with control channel separation to be used with an IPv6 control plane. Davey and Neate Internet Draft [Page 2]
Internet Draft IPv6 Control Channel Separation February 2005 3. Interface Identification A new TLV type is defined to extend the Interface_ID defined in [RFC3471]. The type is 6, IPv6_IF_INDEX (suggested value; to be assigned by IANA). The length is 24 and the value fields have 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Address: 128 bits The IPv6 address field may carry either an IPv6 address of a link or an IPv6 address associated with the router, where associated address is the value carried in an IPv6 router address TLV of routing. That is, the "Router IPv6 Address", [OSPFv3-TE], when the IGP is OSPFv3 and "IPv6 TE Router ID", [ISIS-TE], when the IGP is IS-IS. Interface ID: 32 bits As defined in [RFC3471]. Note that [RFC3471] defines two other types, COMPONENT_IF_DOWNSTREAM and COMPONENT_IF_UPSTREAM with the same format as the IF_INDEX type. However, these types have been deprecated by [MPLS-BUNDLE]. Therefore, no IPv6 equivalents to COMPONENT_IF_DOWNSTREAM and COMPONENT_IF_UPSTREAM are defined. 6. Security Considerations This document raises no new security considerations. 7. IANA Considerations This document defines a new value for the Interface_ID Type: 6. Davey and Neate Internet Draft [Page 3]
Internet Draft IPv6 Control Channel Separation February 2005 8. References 8.1 Normative References [RFC3471] L. Berger, Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description" RFC3471, January 2003. [OSPFv3-TE] K. Ishiguro and T. Takada, "Traffic Engineering Extensions to OSPF version 3", draft-ietf-ospf-ospfv3-traffic-02.txt, July 2004 (work in progress). [ISIS-TE] J. Harrison, J. Berger and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te-00.txt, January 2005 (work in progress). 8.2 Informative References [MPLS-BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling in MPLS Traffic Engineering", draft-ietf-mpls-bundle-06.txt, December 2004 (work in progress). 9. Authors' Addresses Alan Davey Data Connection Ltd 100 Church Street EN2 6BQ U.K. Phone: +44 20 8366 1177 Email: alan.davey@dataconnection.com Nic Neate Data Connection Ltd 100 Church Street EN2 6BQ U.K. Phone: +44 20 8366 1177 Email: nic.neate@dataconnection.com Davey and Neate Internet Draft [Page 4]
Internet Draft IPv6 Control Channel Separation February 2005 9. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Davey and Neate Internet Draft [Page 5]