Hi,
The idea of carrying MPLS labels in IPv6 packet destination options is
already patented by us in 3Com.
We also compiled a ietf-draft in June, but delayed to send out.
Attached below is the draft.
Thanks,
-rajesh
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 30, 2001 6:14 AM
Cc: [EMAIL PROTECTED]
Subject: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPNGLS - IP Next Generation Label Switching
Author(s) : V. Roesler et al.
Filename : draft-roesler-ipngwg-ipngls-00.txt
Pages : 17
Date : 29-Aug-01
This document proposes the forwarding of IPv6 packets using label
switching techniques, with the same advantages of the Multiprotocol
Label Switching (MPLS) architecture. The document proposes the
mapping of all MPLS header fields into the IPv6 header, raising
several advantages like the simplicity of the model, the decrease of
overhead, and others. This mapping was called IP Next Generation
Label Switching, or just IPngLS, and can work concurrently with
MPLS, i.e. IPv6 packets are forwarded with IPngLS and IPv4 packets
are forwarded with MPLS.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-roesler-ipngwg-ipngls-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-roesler-ipngwg-ipngls-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-roesler-ipngwg-ipngls-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Network Working Group Shaji Radhakrishnan
Internet Draft Watercove Networks
June, 2001 Satish Amara
3COM corporation
Rajesh Ramankutty
YingChun Xu
Ellis Wong
WaterCove Networks
MPLS label stack encapsulation in Ipv6
<draft-mpls-label-encaps-ipv6-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 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 obsolete by other documents
at anytime. 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
In certain cases it may be useful to encapsulate MPLS packets in
IPV6 packets. This document describes a method to encapsulate MPLS
in IPV6 networks.
1. Encapsulation in IPv6
The IPv6 destination option or Flow-field will be used to
encapsulate the MPLS label. The LDP on the Egress router and LDP on
the ingress router will agree on what label to use and this label is
encapsulated in the IPV6 flow label. Presently, there are two
mechanisms for LDP peers discovery namely basic discovery and
extended discovery. Basic discovery is used to discover LDP peers,
which are directly connected. Extended discovery is used to discover
LDP peers, which are not directly connected. This mechanism will be
used to establish peering relationship between the LDP running on
Egress and Ingress routers. A new option in the LDP message is
Radhakrishnan, Amara et.al &Expires Nov. 2001 1
< draft-mpls-label-encaps-ipv6-00.txt> November 2001
introduced to convey that extended label is encapsulated in IPV6
destination option or flow-field. Once the label is distributed by
the LDP on egress router to the LDP on Ingress router, then the
egress router will label the packet. The forwarding decision at
Ingress router will be based on destination option or flow-field in
IPV6 packet. If the egress node sets the flow-id field to zero
(i.e., the flow-id is not used for anything else like QoS), then the
flow-id can be used to encapsulate the top field in label stack. If
the flow-id is used to set QoS fields, then the destination
extension header options are used to carry the label or label stack.
If only one label is present in the label stack, the best way is to
use the flow-id for carrying the label, if the flow-id is not used
for any other purpose. But another argument to simplify the
processing at both egress as well as ingress nodes, the extension
header is only used to specify the label stack. With this, the
egress node always use Ipv6 extension header to place the label
stack (whether label stack contains single or multiple labels) and
the ingress node always looks for label extension header to check
label stack.
2. MPLS label stack transport in Ipv6 Extension header
The format of destination option header is the following.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The options are in TLV format as follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type :: 8-bit identifier of the type of option. The proposed
value is 2 for the MPLS label stack.
Opt Data Len :: 8-bit unsigned integer. Length of the Option Data
field of this option, in octets. The length of each label is 32 bits
which 4 bytes, i.e. 20bit label, 1 bit for label stack, 3 bits for
experimental bits and 8 bit for TTL. I.e. if the label stack
contains 3 labels, the size will be 12 bytes.
Radhakrishnan & Amara et. Al, Expires Nov. 2001 2
< draft-mpls-label-encaps-ipv6-00.txt> November 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time To Live field, 8bits
Option Data :: Variable-length field. Option-Type-specific data. The
data contains the encoded MPLS label stack. When placing the label
stack, the label in the top of the stack as the first label, the
next one in the stack will be the second label etc..
<MPLS +----+ +----+ +----+ +----+ <MPLS
------| IP |--------| IP |--------| IP |--------| IP |-----
Cloud> +----+ +----+ +----+ +----+ Cloud>
Egress |<------------IPV6Cloud------------>|Ingress
LSR LSR
3. Label processing at egress node
The outgoing packet will be a normal Ipv6 packet. If the flow-id is
set to zero, then the outgoing label is placed in the flow-id of the
Ipv6 packet. If there is a label stack, each label is placed in the
destination header options in order as described above. The
destination of this Ipv6 packet will be the ingress MPLS router,
which support Ipv6 on the ingress interface. A field in destination
option specifies that the top label (in label stack) is encapsulated
in flow-id.
The TTL field from the label is copied to the Hop Limit field in the
Ipv6 header of the tunneled packet. In the ingress node, the Hop
Limit filed value is copied back to the TTL field of the label.
4. Label processing at ingress node
The ingress node looks for incoming Ipv6 packet and gets the
incoming flow label from the flow-Id of the Ipv6 packets for the
NHFLE entry. The ingress node also looks for any destination header
options for MPLS label stack. If any label stack is present, each
label from the destination option is taken in the order. The first
label should be the top of the stack, the second label will be the
second one from the top etc.. The label and stack processing are
done as described in the MPLS architecture.
In certain cases (i.e., when security is not applied to the original
packet end-to-end) instead of tunneling MPLS packet in IPV6 packets
by the egress node, the packets can be transported in IPV6 packets
Radhakrishnan & Amara et. Al, Expires Nov. 2001 3
< draft-mpls-label-encaps-ipv6-00.txt> November 2001
using routing header option. In that case the routing header would
specify the route. Routing header will contain two entries. The
first hop in the routing header will be Ingress router and the final
hop will be destination IP address of the packet.
5. Security Considerations
Security issues are not discussed in this document.
6. References
[1] E. Rosen et.al �MPLS Label Stack Encoding�.
RFC3032, January 2001.
[2] E. Rosen et.al �Multiprotocol Label Switching Architecture�.
RFC3031
[3] L. Andersson et al, "LDP Specification,"
Internet-RFC 3036, Jan 2001.
[4] Internet Protocol, Version 6 (IPv6) Internet-RFC 2460
[5] J. Reynolds and J. Postel. "ASSIGNED NUMBERS". RFC1700, October
1994.
Author's Addresses
Shaji Radhakrishnan
WaterCove Networks
1750 East Golf Road, Suite 550
Schaumburg, IL 60173
Phone: (847) 621-8913
Email: [EMAIL PROTECTED]
Satish Amara
3Com Corporation
3800, Golf Road,
Rolling Meadows, IL 60008
Phone: 847-262-2563
Email: [EMAIL PROTECTED]
Rajesh Ramankutty
3Com Corporation
3800, Golf Road,
Rolling Meadows, IL 60008
Phone: 847-262-2580
Email: [EMAIL PROTECTED]
Yingchun Xu
WaterCove Networks
Radhakrishnan & Amara et. Al, Expires Nov. 2001 4
< draft-mpls-label-encaps-ipv6-00.txt> November 2001
1750 East Golf Road, Suite 550
Schaumburg, IL - 60173
Phone: (847) 477-9280
Email: [EMAIL PROTECTED]
Ellis Wong
WaterCove Networks
285 Billerica Road
Chelmsford, MA - 01824
Phone: (978) 608-2089
Email: [EMAIL PROTECTED]
Radhakrishnan & Amara et. Al, Expires Nov. 2001 5
