Internet DRAFT - draft-eng-nalawade-ospf-tunnel-cap
draft-eng-nalawade-ospf-tunnel-cap
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]
