INTERNET-DRAFT A. Davey draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00 Data Connection Ltd (DCL) Category: Informational A. Farrel Expires: September 2005 Old Dog Consulting T. Nadeau Cisco Systems, Inc. March 2005 Handling IPv6 Sources and Destinations in the MPLS and GMPLS TE MIB Modules <draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt> Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 describes how to configure or monitor a Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) using the MPLS and GMPLS TE MIB module where the ingress and/or egress routers are identified using IPv6 addresses. Davey et al Informational [Page 1]
Internet Draft IPv6 Sources and Destinations in TE MIB 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 This document defines a method of defining or monitoring an LSP tunnel using the MPLS TE MIB module [RFC3812] and GMPLS TE MIB module [GMPLSTEMIB] where the ingress and/or egress routers are identified using 128-bit IPv6 addresses. That is, where the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end point address and Extended Tunnel Id fields from the signaled Session Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is in use. Davey et al Informational [Page 2]
Internet Draft IPv6 Sources and Destinations in TE MIB February 2005 3. Identifying LSRs For this feature to be used, all LSRs in the network MUST advertise a 32-bit value that can be used to identify the LSR. In this document, this is referred to as the 32-bit router ID. The 32-bit router ID may be, for example, the OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. 4. Configuring GMPLS tunnels with IPv6 Source and Destination Addresses When setting up RSVP TE tunnels, it is common practice to copy the values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel ID and IPv4 tunnel end point address fields, respectively, in the RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209]. This approach cannot be used when the ingress and egress routers are identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields are defined to be 32-bit values [RFC3811] and [RFC3812]. Instead, the IPv6 addresses SHOULD be configured in the mplsHopTable as the first and last hops of the mplsTunnelHopTable entries defining the explicit route for the tunnel. Note that this implies that a tunnel with IPv6 source and destination addresses MUST have an explicit route configured, although it should be noted that the configuration of an explicit route in this way does not imply that an explicit route will be signaled. In more detail, the tunnel is configured at the ingress router as follows. See [RFC3812] for definitions of MIB table objects and for default (that is, "normal") behavior. The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields SHOULD be set to 32-bit router IDs for ingress and egress LSR respectively. The mplsTunnelHopTableIndex MUST be set to a non-zero value. That is, an explicit route MUST be specified. The first hop of the explicit route MUST have mplsTunnelHopAddrType field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the ingress router that is reachable in the control plane. The last hop of the explicit route MUST have mplsTunnelHopAddrType field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the egress router that is reachable in the control plane. Davey et al Informational [Page 3]
Internet Draft IPv6 Sources and Destinations in TE MIB February 2005 The ingress router SHOULD set the signaled values of the Extended Tunnel ID and IPv6 tunnel end point address fields, respectively, of the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the mplsTunnelHopIpAddr object of the first and last hops in the configured explicit route. 5. Managing and Monitoring Tunnel Table Entries The TE MIB module may be used for managing and monitoring MPLS and GMPLS TE LSPs, as well as configuring them as described in section 4. This function is particularly important at egress and transit LSRs. For a tunnel with IPv6 source and destination addresses, an LSR implementation SHOULD return values in the mplsTunnelTable as follows (where "normal" behavior is the default taken from [RFC3812]). The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to 32-bit router IDs. That is, each transit and egress router maps from the IPv6 address in the Extended Tunnel ID field to the 32-bit router ID of the ingress LSR. Each transit router also maps from the IPv6 address in the IPv6 tunnel end point address field to the 32-bit router ID of the egress LSR. 6. Mixed IPv4 and IPv6 Source and Destination This document has focused on the case where both ingress and egress are identified by IPv6 addresses. It is also possible that only one of the two addresses comes from the IPv6 space. In this case only the text applying to the ingress or egress (as appropriate) should be applied. 7. Security Considerations This informational document describes procedures for using existing MIB modules and signaling protocols but does not define any new behavior of the signaling protocol, nor any new configuration operations. As such, no new security considerations are introduced. Readers should be aware of the security considerations set out in the related MIB documents [RFC3812] and [GMPLSTEMIB], as well as those described for the signaling protocols in [RFC3209] and [RFC3473]. 8. IANA Considerations This document raises no new IANA considerations. Davey et al Informational [Page 4]
Internet Draft IPv6 Sources and Destinations in TE MIB February 2005 9. References 9.1 Normative References [GMPLSTEMIB] Thomas D. Nadeau and Adrian Farrel, editors, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", draft-ietf-ccamp-gmpls-te-mib, (work in progress). [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3209] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. 9.2 Informative References [RFC2740] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, April 1998. [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. Davey et al Informational [Page 5]
Internet Draft IPv6 Sources and Destinations in TE MIB February 2005 10. Authors' Addresses Alan Davey Data Connection Ltd 100 Church Street EN2 6BQ U.K. Phone: +44 20 8366 1177 Email: alan.davey@dataconnection.com Adrian Farrel Old Dog Consulting Phone: +44-(0)-1978-860944 Email: adrian@olddog.co.uk Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Davey et al Informational [Page 6]
Internet Draft IPv6 Sources and Destinations in TE MIB February 2005 11. 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 et al Informational [Page 7]