INTERNET-DRAFT 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 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]