Internet DRAFT - draft-ishii-rsvp-te-ipv4-ipv6-extension
draft-ishii-rsvp-te-ipv4-ipv6-extension
INTERNET-DRAFT
<draft-ishii-rsvp-te-ipv4-ipv6-extension-00.txt>
Expires: August 20, 2002 Hideo Ishii
Asia Global Crossing
Koichiro Fujimoto
NEC Corporation
Shinji Sugiyama
NEC Corporation
Hiroki Ishibashi
NEC Corporation
February 21, 2002
RSVP-TE Extension for IPv4/IPv6 Dual Stacking PE
under IPv4 MPLS Core Environment
<draft-ishii-rsvp-te-ipv4-ipv6-extension-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 August 20, 2002.
Ishii, et al Expires August 20, 2002 [Page 1]
INTERNET-DRAFT RSVP-TE Extension for IPv4/IPv6 Dual PE February 2002
Abstract
This document specifies a method to establish Label Switch Paths
(LSPs) for IPv4 and IPv6 traffic interminglement over IPv4 MPLS
network using [RSVP-TE]. IP version(s) of traffic to be transmitted
over the established LSP can be recognized by egress routers using
new SESSION_ATTRIBUTE type. IPv4 Label Switch Routers (LSRs) are not
required to have knowledge about the Provider Edge (RE) Routers which
support this extension.
1. Introduction
This document describes new C-Type for SESSION_ATTRIBUTE (207)
defined in [RSVP-TE]. Through this SESSION_ATTRIBUTE C-Type, an
ingress router can notify IP version(s) to be transmitted over
establishing LSP to an egress router. If the egress router is not
willing to accept the IP version(s) specified by the ingress router,
it sends a Reserve Error message with new error code defined in this
document.
The extension to [RSVP-TE] described in this documents is intended to
simplify the mechanism to establish LSPs for IPv6 and IPv4 separately
or both inclusively over IPv4 MPLS network.
2. Application Model
There are many existing networks which have been built by [RSVP-TE].
Building IPv6-capable IPv4 MPLS LSPs enables us to:
a) Deploy stable IPv6 networks onto IPv4 MPLS network.
b) 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:
a) Efficient packet forwarding by minimizing transmission
overheads.
b) Making the most of the existing network management tools for
IPv4 MPLS.
c) Early deployment of IPv6 Traffic Engineering. Routing
Protocols are sent over the established IPv4 MPLS LSP.
By doing this, PE routers can exchange routing information
Ishii, et al Expires August 20, 2002 [Page 2]
INTERNET-DRAFT RSVP-TE Extension for IPv4/IPv6 Dual PE February 2002
directly over Provider (P) routers. Therefore, P routers
are not required to have any knowledge of IPv6 Routing
information. Any routing protocol can be applied among
PE routers. 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.
3. Mechanism
The mechanism to establish IPv4 MPLS LSPs on which IPv6 and IPv4
traffic is to be sent is described in this section as a model case.
Node.A --------------- ( IPv4 MPLS Cloud ) --------------- Node.B
3.1 Setting Up IPv4 MPLS LSPs for IPv6 and IPv4 traffic (on a single
LSP)
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:
a) Send a [RSVP-TE] Path Message from Node.A to Node.B to initiate
Label request from Node.A with IP version(s) information to be
transmitted using new SESSION_ATTRIBUTE C-Type. In this case,
IPv4 and IPv6 are specified. If Node.B is willing to accept
IPv4 and IPv6, an IPv4 MPLS LSP in the direction of Node.A to
Node.B is established. Otherwise, Node.B notifies the
unsupported IP version to Node.A using a Reserve Error message.
b) 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 using new SESSION_ATTRIBUTE C-Type.
4. SESSION_ATTRIBUTE LSP_TUNNEL_DESIRED_IP_VERSION C-Type
Notification of IP version(s) to be transmitted is accomplished with
SESSION_ATTRIBUTE LSP_TUNNEL_DESIRED_IP_VERSION C-Type.
LSP_TUNNEL_DESIRED_IP_VERSION C-Type includes all the same fields as
the LSP_TUNNEL C-Type. Additionally it carries IP version
information. The format is as follows:
Ishii, et al Expires August 20, 2002 [Page 3]
INTERNET-DRAFT RSVP-TE Extension for IPv4/IPv6 Dual PE February 2002
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_DESIRED_IP_VERSION C-Type =
TBD.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IP Version Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved. It MUST be set to zero on transmission
and ignored on receipt.
IP Version Flags
0x01 IPv4 desired
This flag permits IPv4 traffic to be transmitted over the
established IPv4 MPLS LSP using [RSVP-TE].
0x02 IPv6 desired
This flag permits IPv6 traffic to be transmitted over the
established IPv4 MPLS LSP using [RSVP-TE].
Setup Priority
The priority of the session with respect to taking resources,
in the range of 0 to 7. The value 0 is the highest priority.
The Setup Priority is used in deciding whether this session can
preempt another session.
Holding Priority
The priority of the session with respect to holding resources,
in the range of 0 to 7. The value 0 is the highest priority.
Holding Priority is used in deciding whether this session can
be preempted by another session.
Flags
Ishii, et al Expires August 20, 2002 [Page 4]
INTERNET-DRAFT RSVP-TE Extension for IPv4/IPv6 Dual PE February 2002
0x01 Local protection desired
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
Name Length
The length of the display string before padding, in bytes.
Session Name
A null padded string of characters.
4.1 Ingress router behavior
The ingress router creates a path message which includes
SESSION_ATTRIBUTE LSP_TUNNEL_DESIRED_IP_VERSION C-Type Object. IP
version(s) which the ingress router is going to transmit is to be
specified in the IP Version Flags. For example, if IPv4 and IPv6
traffic is going to be transmitted, 0x01 (IPv4 desired) and 0x02
(IPv6 desired) are set in the IP Version Flags.
4.2 Egress router behavior
On receiving a valid path message with SESSION_ATTRIBUTE
LSP_TUNNEL_DESIRED_IP_VERSION C-Type Object, the egress router
examines the IP Version Flags. If IP version(s) specified by the
ingress router is acceptable, the egress router configures itself to
accept the specified IP version(s). Otherwise, the egress router
sends a Reserve Error message with error codes and sub-Codes defined
below.
Ishii, et al Expires August 20, 2002 [Page 5]
INTERNET-DRAFT RSVP-TE Extension for IPv4/IPv6 Dual PE February 2002
Error Code Meaning
TBD LSP TUNNEL IP Version Problem
This error code has the following globally-defined
Error Value
sub-codes:
1 IPv4 is not accepted
2 IPv6 is not accepted
5. Security Consideration
The same security consideration as in [RSVP-TE] is applicable.
Ishii, et al Expires August 20, 2002 [Page 6]
INTERNET-DRAFT RSVP-TE Extension for IPv4/IPv6 Dual PE February 2002
6. References
[RSVP-TE] Awduche, Berger, Gan, Li, Srinivasan, and Swallow, " RSVP-
TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
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
Ishii, et al Expires August 20, 2002 [Page 7]
