One document matched: draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt

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]