Network Working Group K. Ishiguro
Internet Draft IP Infusion Inc.
Expiration Date: October 2003 T. Takada
IP Infusion Inc.
April 2003
Traffic Engineering Extensions to OSPF version 3
draft-ietf-ospf-ospfv3-traffic-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
This document describes extensions to the OSPF version 3 to support
intra-area Traffic Engineering.
This document expands OSPFv2 traffic engineering to make both IPv4
and IPv6 network applicable. New sub-TLVs are defined to support
IPv6 network. Use of these new sub-TLVs are not limited in OSPF
version 3. They can be used in OSPF version 2.
1. Applicability
OSPFv3 has a very flexible mechanism in terms of adding new LS type.
Ishiguro Expires October 2003 [Page 1]
Internet Draft draft-ietf-ospf-ospfv3-traffic-00.txt April 2003
Even the implementation does not know the LS types, the LSA is
properly flooded by LS type field. This document adds a new LSA type
Intra-Area-TE-LSA to OSPFv3.
For Traffic Engineering, this document refers [1] as a basement TLV
definition documentation. New sub-TLVs are added to [1] to provide
applicability to OSPFv3. Some TLVs need clarification of their usage
and value to apply to OSPFv3. Newly added sub-TLVs can be used in
[1] also.
Once [1] becomes applicable to OSPFv3, other mechanism such as [2]
and [3] which use [1] can be applicable to OSPFv3.
2. Router Address TLV
In OSPFv3, Router Address TLV value should be a Router ID of the
advertising router. [1] states Router Address TLV is "a stable IP
address of the advertising router that is always reachable if there
is any connectivity to it". In OSPFv3, Router ID is not a real IP
address and is not reachable in IPv6 network. In OSPFv3 router
identifier and IP address is completely separated. For eachability
information, Router IPv6 Address TLV is used.
The Router Address TLV is type 1, and has a length of 4, and the
value is the four octet OSPFv3 Router ID. It must appear in exactly
one Traffic Engineering LSA originated by a router.
3. Router IPv6 Address TLV
A new TLV is introduced to carry reachable IPv6 address. This IPv6
address is always reachable address to resolve the router's
reachability.
The Router IPv6 Address TLV is type 3, and has a length of 16. It
must appear in exactly one Traffic Engineering LSA originated by a
router.
4. Link TLV
The Link TLV describes a single link. It is constructed of a set of
sub-TLVs. Except Link ID sub-TLV, all of other sub-TLVs defined in
[1] can be applicable to OSPFv3. Link ID sub-TLV can't be used in
OSPFv3 due to the protocol difference between OSPFv2 and OSPFv3.
Three new sub-TLVs are defined in this document: Neighbor ID, Local
Ishiguro Expires October 2003 [Page 2]
Internet Draft draft-ietf-ospf-ospfv3-traffic-00.txt April 2003
Interface IPv6 address and Remote Interface IPv6 address.
17 - Neighbor ID (8 octets)
18 - Local Interface IPv6 Address (16N octets)
19 - Remote Interface IPv6 Address (16N octets)
4.1 Link ID
Link ID sub-TLV is used in OSPFv2 to identify the other end of the
link. In OSPFv3, Neighbor ID should be used instead of Link ID. In
OSPFv3, the Link ID sub-TLV should not be sent and ignored upon
receipt.
4.2 Neighbor ID
In OSPFv2, Link ID is a unique key to identify the other end of the
link. In OSPFv3, to identify the other end of the link, the combina-
tion of Neighbor Interface ID and Neighbor Router ID is needed. So
new sub-TLV Neighbor ID is defined.
The Neighbor ID sub-TLV is TLV type 17, and is 8 octets in length.
It contains 4 octet Neighbor Interface ID and 4 octet Neighbor Router
ID. Neighbor Interface ID and Neighbor Router ID value is the same
as described in [OSPFV3] A.4.3 Router-LSAs.
In OSPFv2, the Neighbor ID sub-TLV should not be sent and ignored
upon receipt.
4.3 Local Interface IPv6 Address
The Local Interface IPv6 Address sub-TLV specifies the IPv6
address(es) of the interface corresponding to this link. If there
are multiple local addresses on the link, they are all listed in this
sub-TLV. Link-local address should not be included in this sub-TLV.
The Local Interface IPv6 Address sub-TLV is TLV type 18, and is 16N
octets in length, where N is the number of local addresses.
4.4 Remote Interface IPv6 Address
The Remote Interface IPv6 Address sub-TLV specifies the IPv6
address(es) of the neighbor's interface corresponding to this link.
This and the local address are used to discern multiple parallel
links between systems. If the Link Type of the link is Multiaccess,
Ishiguro Expires October 2003 [Page 3]
Internet Draft draft-ietf-ospf-ospfv3-traffic-00.txt April 2003
the Remote Interface IPv6 Address is set to ::. Link-local address
should not be included in this sub-TLV.
The Remote Interface IPv6 Address sub-TLV is TLV type 19, and is 16N
octets in length, where N is the number of neighbor addresses.
5. Intra-Area-TE-LSA
New LS type Intra-Area-TE-LSA is defined. LSA function code is 10.
U bit is 1 to indicate that router should handle the LSA even if the
router does not recognize the LSA's function code. Flooding scope is
Area Scoping. So Intra-Area-TE-LSA's LS Type is 0xa00a.
LSA function code LS Type Description
--------------------------------------------------------------------
10 0xa00a Intra-Area-TE-LSA
Link State ID of Intra-Area-TE-LSA should be the Interface ID of the
link.
6. Security Considerations
Security issues are not discussed in this memo.
7. Acknowledgements
Thanks to Vishwas Manral, Kireeti Kompella and Alex Zinin for their
comments.
8. Reference
[1] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF", draft-katz-yeung-ospf-traffic-09.txt, work
in progress.
[2] K. Kompella, Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-09.txt,
work in progress.
[3] F. L. Faucheur, J. Boyle, K. Kompella, W. Townsend, D. Skalecki,
"Protocol extensions for support of Diff-Serv-aware MPLS Traffic
Engineering", draft-ietf-tewg-diff-te-proto-02.txt, work in
Ishiguro Expires October 2003 [Page 4]
Internet Draft draft-ietf-ospf-ospfv3-traffic-00.txt April 2003
progress.
9. Author's Address
Kunihiro Ishiguro
IP Infusion Inc.
111 W. St. John Street, Suite 910
San Jose CA 95113
e-mail: kunihiro@ipinfusion.com
Toshiaki Takada
IP Infusion Inc.
111 W. St. John Street, Suite 910
San Jose CA 95113
e-mail: takada@ipinfusion.com
Ishiguro Expires October 2003 [Page 5]
