Internet DRAFT - draft-davey-ccamp-gmpls-ipv6-if-index
draft-davey-ccamp-gmpls-ipv6-if-index
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]
