Internet DRAFT - draft-ishii-ipv6-te-tunnel
draft-ishii-ipv6-te-tunnel
INTERNET-DRAFT Hideo Ishii
<draft-ishii-ipv6-te-tunnel-00.txt> Asia Global Crossing
Expires: May 13, 2002
Koichiro Fujimoto
NEC Corporation
Shinji Sugiyama
NEC Corporation
Hiroki Ishibashi
NEC Corporation
November 13, 2001
IPv6 Traffic Engineering Tunnel
<draft-ishii-ipv6-te-tunnel-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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration
will be May 13, 2002.
Abstract
This document specifies a method to transmit IPv6 traffic over IPv4
MPLS Label Switched Paths (LSPs) constructed by [RSVP-TE]. The way
Ishii, et al Expires: May 13, 2002 [Page 1]
INTERNET-DRAFT IPv6 Traffic Engineering Tunnel November 2001
to transmit IPv4 and IPv6 traffic over IPv4 MPLS LSPs and the way to
exchange routing information are described. This method allows
Traffic Engineering for IPv4 and IPv6 separately or both inclusively.
1. Introduction
There are many existing networks which have been built by [RSVP-TE].
Building IPv6-capable IPv4 MPLS LSPs enables us to:
1. deploy stable IPv6 networks.
2. make the most of existing network equipment and production
software code as core LSR.
The method described in this document has the following advantages
over the IPv6-over-IPv4 tunnel:
1. efficient packet forwarding by minimizing transmission
overheads.
2. making the most of the existing network management tools for
IPv4 MPLS.
3. early deployment of IPv6 Traffic Engineering.
2. Mechanism
The mechanism to establish IPv4 MPLS LSPs on which IPv6 traffic is to
be sent is described in this section.
Node.A ----- ( MPLS Cloud ) ----- Node.B
2.1 Setting Up IPv4 MPLS LSPs
IPv4 MPLS LSPs are established on the IPv4 control plane using [RSVP-
TE]. IPv4 addresses are used to specify each provider edge (PE)
router. Therefore, when an explicit route object of [RSVP-TE] is to
be used, IPv4 addresses are used, too.
On the network diagram above, the steps to establish IPv4 MPLS LSPs
are:
1. Send a [RSVP-TE] Path Message from Node.A to Node.B to initiate
Label request from Node A.
In this step, an IPv4 MPLS LSP in the direction of Node.A to
Ishii, et al Expires: May 13, 2002 [Page 2]
INTERNET-DRAFT IPv6 Traffic Engineering Tunnel November 2001
Node.B is established.
2. Likewise, an IPv4 MPLS LSP in the direction of Node.B to Node.A
is established by sending a [RSVP-TE] Path Message from Node.B
to Node.A.
2.2 Setting Up the IP Version
By default, both IPv4 and IPv6 are transmitted over the established
IPv4 MPLS LSP using [RSVP-TE]. On a PE Router, a user may explicitly
configure which LSP should be used to forward IPv4 traffic and IPv6
traffic, independently. An IPv4 MPLS LSP may be configured only for
IPv6. Another may be configured for both IPv4 and IPv6. Since an
LSP is a unidirectional path, it may be required to configure IP
versions on both node.A and Node.B.
2.3 Routing IPv6
Routing Protocols are sent over the established IPv4 MPLS LSP. By
doing this, PE routers can exchange routing information directly over
Provider (P) routers. Therefore, P routers are not required to have
any knowledge of IPv6 Routing information. Using this method, PE
routers can detect the loss of reachability and update routing
information when the IPv4 MPLS LSP is torn down. This mechanism can
prevent packets from going into the black hole.
The examples of routing protocol settings are described below:
1. BGP4 and BGP4+
For IPv6, link-local addresses can be specified as neighbors.
When IPv6 Global and IPv4 addresses are used, BGP packets may
be routed outside of IPv4 MPLS LSPs; therefore, it is desirable
to set TTLs to one.
2. RIP, RIPng, OSPFv2, and OSPFv3
Basically, any routing protocols can be configured by setting
respective routing protocols on tunnel interfaces which are
entry points to IPv4 MPLS LSPs since a neighboring PE router is
one hop away over an IPv4 MPLS LPS.
3. Traffic Engineering Consideration
By specifying IP versions to be transmitted over a certain IPv4 MPLS
LSP as described in 2.2, it is possible to manage and control IPv4
and IPv6 traffic independently. Using this method, IPv4 and IPv6
traffic can be separated on different IPv4 MPLS LSPs or together with
Ishii, et al Expires: May 13, 2002 [Page 3]
INTERNET-DRAFT IPv6 Traffic Engineering Tunnel November 2001
on a single IPv4 MPLS LSP.
4. Security Consideration
The same security consideration as in [RSVP-TE] is applicable.
5. Future Work
As described in the section 2.2, currently, it may be required to
configure IP versions to be transmitted over IPv4 MPLS LSPs. The way
to identifying the version of incoming IP packets and finding the
corresponding label automatically are to be discussed in the future.
Ishii, et al Expires: May 13, 2002 [Page 4]
INTERNET-DRAFT IPv6 Traffic Engineering Tunnel November 2001
6. References
[RSVP-TE] Awduche, Berger, Gan, Li, Srinivasan, and Swallow, "RSVP-
TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-
tunnel-09.txt, work in progress.
7. Author's Addresses
Hideo Ishii
Asia Global Crossing
17F Kamiyacho Mori Bldg. 4-3-20 Toranomon,
Minato-ku, Tokyo 105-0001 Japan
Email: hishii@gblx.net
Koichiro Fujimoto
NEC Corporation
7-1, Shiba 5-Chome,
Minato-ku, Tokyo 108-8001 Japan
Email: koichiro@ipv6.nec.co.jp
Shinji Sugiyama
NEC Corporation
1131 Hinode,
Abiko City, Chiba 270-1198 Japan
sugiyama@ipv6.nec.co.jp
Hiroki Ishibashi
NEC Corporation
1131 Hinode,
Abiko City, Chiba 270-1198 Japan
bashi@ipv6.nec.co.jp
