Network Working Group Sandy Eng Internet Draft Gargi Nalawade Expires: March 2004 Peter Psenak Cisco Systems OSPF Tunnel capability TLVs draft-eng-nalawade-ospf-tunnel-cap-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As increasing number of tunnels are deployed in a Provider core, there is a need for improving the efficiency and ease of tunnel establishment. OSPF running as the IGP in a Provider core, can act as the signalling agent for the Tunnel endpoints. OSPF can carry tunnel endpoint information in the intra-AS scope, easing BGP of the extra burden of signalling within the core. 1. Introduction draft-eng-nalawade-ospf-tunnel-00.txt [Page 1] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 Two end-points of a Tunnel need to know the end-point information and its binding to a network address at the remote point. Normally, this can be statically shared and configured. But in case of a large network where there may be a need for a large number of tunnels. The number of tunnel end-points that would need to be configured and maintained soon becomes unmanageable. This draft proposes using OSPF for signalling the Tunnel endpoints and introdcues an OSPF IPv4 tunnel capability TLV that will be carried within the OSPF router information LSA. 2. Specification This document defines a Tunnel TLV to be carried in the OSPF Router Information LSA. The Tunnel Information TLV has a type of 4. The first twelve bytes contain the following : - Address Type (2 octects) - Reserved (6 octects) - Tunnel endpoint address (4 or 16 octects) - Tunnel ID (2 Octets) - Tunnel-Group ID (2 Octets) This is followed by tunnel sub-TLVs which MUST be included. The Tunnel TLV looks as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel endpoint address (4 - 16 octects) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID (2 octects) | Tunnel-Group ID (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | sub-TLV(s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-eng-nalawade-ospf-tunnel-00.txt [Page 2] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 where Type: identifies the Tunnel TLV type and will have a value of 4 Length: length of the value field in octets Address Type : defines the Address-Type used as defined for AFIs by [9] Tunnel endpoint address : is a 4-octet address for the IPv4 Tunnel TLV and 16-octet for the IPv6 Tunnel TLV. Tunnel ID : is a 2-octet identifier to identify a Tunnel endpoint Tunnel-Group ID : is a 2-octet global group Identifier used by all PE endpoints who are interested in establishing tunnel relationships with each other. sub-TLVs : will contain Tunnel encapsulation sub-TLVs. Eg. 1 : L2TPv3 Tunnel information 2 : mGRE Tunnel information 3 : IPSec Tunnel information 4 : MPLS Tunnel information 2.1. OSPF L2TPv3 tunnel sub-TLV The L2TPv3 Tunnel Information TLV has a type value of 1. The value part of the L2TPv3 Tunnel Information Type contains the following : - Preference (2 Octets) - Flags (1 Octet) - Cookie Length (1 Octet) - Session ID (4 Octets) - Cookie (Variable) The L2TPv3 Tunnel sub-TLV looks as follows : draft-eng-nalawade-ospf-tunnel-00.txt [Page 3] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type = 1 | Length (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference (2 octects) |S| Flags | Cookie Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID (4 Octects) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie (Variable, 0 or 8 octexts) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Length : is a multiple of 4 octects. Preference : is a 2-octet field containing a Preference associated with the TLV. The Preference value indicates a preferred ordering of tunneling encapsulations according to the sender. The recipient of the information SHOULD take the sender's preference into account in selecting which encapsulation it will use. A higher value indicates a higher preference. Flags : is a 1-octet field containing flag-bits. The leftmost bit indicates whether Sequence numbering is to be used or not. The remaining bits are reserved for future use. Cookie Length : is a 1-octet field that contains the length of the variable length Cookie. Session ID : is a 4-octet field containing a non-zero identifier for a session. Cookie : is a variable length (maximum 64 bits), value used by L2TPv3 to check the association of a received data message with the session identified by the Session ID. 2.2. OSPF mGRE Tunnel sub-TLV The OSPF mGRE Tunnel sub-TLV has a type value of 2. The value part of the mGRE Tunnel Information Type contains the following : draft-eng-nalawade-ospf-tunnel-00.txt [Page 4] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 - Preference (2 Octets) - Flags (1 Octet) - mGRE Key (0 or 4 Octets) The mGRE Tunnel sub-TLV looks as follows : 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type = 2 | Length (8 octects) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference (2 octects) |S|K| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mGRE Key (4 Octects) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Length : is 8 octets. Preference : is a 2-octet field containing a Preference associated with the TLV. The Preference value indicates a preferred ordering of tunneling encapsulations according to the sender. The recipient of the information SHOULD take the sender's preference into account in selecting which encapsulation it will use. A higher value indicates a higher preference. Flags : is 1-octet field containing flag-bits. The leftmost bit indicates whether Sequence numbering is to be used or not. The 2nd bit indicates whether an mGRE Key is present or not. The remaining bits are reserved for future use. mGRE Key : A 4-octet field containing an optional mGRE Key. 3. Operation A router must originate a new OSPF router information LSA whenever the content of the Tunnel TLV changes or whenever required by the regular OSPF procedure (LSA refresh (every LSRefreshTime, ...)). The Tunnel TLV may be carried within either a type 10 or 11 router information LSA. As defined in RFC2370, an opaque LSA has a flooding scope determined by its LSA type: draft-eng-nalawade-ospf-tunnel-00.txt [Page 5] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 - area-local (type 10) - entire OSPF routing domain (type 11) If all Tunnel endpoints lie within a single area, a type 10 router infomation LSA must be generated. If the Tunnel endpoints span multiple OSPF areas, a type 11 router information LSA must be generated. 4. Deployment Considerations and Interoperability In an IP VPN environment, this specification does not require any provider core routers to be upgraded. Only routers who are interested to be tunnel endpoints are required to understand this specification. This poses no backward compatibility issue as routers which do not understand this specification will simply ignore the TLVs. 5. Security Considerations This extension to OSPF does not change the underlying security issues. 6. Acknowledgements The authors would like to thank Steven Luong, Raja Daoud, Dan Tappan, Jean-Phillip Vasseur and Eric Rosen for their inputs and comments. 7. References [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. . [2] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-04.txt [3] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998 [4] Aggarwal et all, ''Extensions to IS-IS and OSPF for Advertising Optional Router Capabilities'', Internet draft, draft-raggarwa-igp- cap-01.txt, October 2002. [5] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP- 4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. draft-eng-nalawade-ospf-tunnel-00.txt [Page 6] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 [6] Nalawade G., Kapoor R., Tappan D., "BGP IPv4-Tunnel SAFI", draft-nalawade-kapoor-tunnel-safi-00.txt, work in progress. [7] Bates et al, Multiprotocol Extensions for BGP-4, draft- ietf- idr-rfc2858bis-02.txt, work in progress. [8] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [9] http://www.iana.org/assignments/address-family-numbers 8. Authors' Addresses Sandy Eng mailto:swkeng@cisco.com Gargi Nalawade mailto:gargi@cisco.com Peter Psenak mailto:ppsenak@cisco.com Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95134 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. draft-eng-nalawade-ospf-tunnel-00.txt [Page 7] Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt September 2003 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." draft-eng-nalawade-ospf-tunnel-00.txt [Page 8]