One document matched: draft-lee-xcast-tunneling-01.txt
Differences from draft-lee-xcast-tunneling-00.txt
INTERNET-DRAFT Jiwoong Lee
Expires: Feb 2003 KTF
09 August 2002
Explicit Multicast Tunneling
<draft-lee-xcast-tunneling-01.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.
All remarks may be forwarded to author's email address or xcast
IG(Incubation Group) mailing list: xcast@public.alcatel.com
Abstract
Explicit multicast(Xcast)[1], as a new kind of Internet multicast,
encodes the list of destinations within its packet. This document
specifies tunneling scheme of xcast packets. Since a single xcast
tunnel has multiple egress-nodes, the original xcast packet can be
encapsulated either within a xcast packet or within a unicast
packet. When tunneled by Xcast-in-Xcast encapsulation, the bitmap
of the original xcast packet is overwritten with the bitmap of the
tunnel xcast packet at tunnel egress-nodes, in order to guarantee
the active destination set.
Jiwoong Lee Expire Feb 2003 [Page 1]
INTERNET-DRAFT Xcast Tunneling Aug 2002
Table of Contents
Status of this memo . . . . . . . . . . . . . . . . . . . . . . . . 1
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Xcast-in-Xcast encapsulation . . . . . . . . . . . . . . . . . 4
1.2. Xcast-in-Unicast encapsulation . . . . . . . . . . . . . . . . 4
2. Terminology and semantics . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Xcast-in-Xcast tunneling . . . . . . . . . . . . . . . . . . . 7
3.2. Xcast-in-Unicast tunneling . . . . . . . . . . . . . . . . . . 9
4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Xcast-in-Xcast encapsulation . . . . . . . . . . . . . . . . . 11
4.1.1. Message format in IPv4 . . . . . . . . . . . . . . . . . . . 13
4.1.2. Message format in IPv6 . . . . . . . . . . . . . . . . . . . 14
4.2. Xcast-in-Unicast encapsulation . . . . . . . . . . . . . . . . 16
5. Decapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Xcast-in-Xcast decapsulation . . . . . . . . . . . . . . . . . 16
5.2. Xcast-in-Unicast decapsulation . . . . . . . . . . . . . . . . 17
6. Transit node operations . . . . . . . . . . . . . . . . . . . . . 17
6.1. Tunnel branching node operation . . . . . . . . . . . . . . . . 17
6.2. Nested Xcast tunneling . . . . . . . . . . . . . . . . . . . . 17
7. Multicast-in-Xcast tunneling . . . . . . . . . . . . . . . . . . 17
8. ICMP message processing . . . . . . . . . . . . . . . . . . . . . 18
8.1. Xcast-in-Xcast tunnel . . . . . . . . . . . . . . . . . . . . . 18
8.2. Xcast-in-Unicast tunnel . . . . . . . . . . . . . . . . . . . . 19
9. Tunnel soft state management . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 19
CHANGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Jiwoong Lee Expire Feb 2003 [Page 2]
INTERNET-DRAFT Xcast Tunneling Aug 2002
1. Introduction
This document specifies generic mechanism by which an Explicit
multicast packet is encapsulated and decapsulated. An xcast packet
can be encapsulated within xcast or unicast packet.
The main goal of the encapsulation is tunneling packets. A tunnel
is a virtual forwarding path on which the payloads of packets are
original packets between one encapsulating node and at least one
decapsulating node. Within a tunnel, the tunneled packet is not
tampered by transit nodes.
Experimental virtual links, Virtual Private Networks, Mobile IP
networks and etc. require tunneling between involved nodes for
their normal operations. Tunneling mechanism used for encapsulation
of unicast packets are well defined in [7][6][9] and has been
widely used throughout the Internet.
Explicit multicast[1] is a new kind of Internet multicast, in which
every packet carries plural unicast addresses of all the
destinations within it. Since xcast packets are addressed to more
than a single destination, the definition of tunnel, decision of
tunnel egress-nodes, processes of encapsulation and decapsulation
should be different from those of unicast packet tunneling.
When an xcast packet is received by a tunnel ingress node, the
ingress node encapsulates it within xcast, or unicast packet, and
sends the encapsulated packet to the tunnel egress-nodes. When an
encapsulated xcast packet is received by an egress node, the egress
node decapulates it and routes the original packet. This series of
operations is called xcast tunneling.
In particular, the tunnel has one or more tunnel egress-nodes and
one tunnel ingress node. A tunnel can be identified by a pair of
node information, ( I, E* ) where I stands for the tunnel ingress
node and E* stands for the set of tunnel egress-nodes. The
cardinality of E* is at least one. That is, an xcast tunnel has the
form of one-to-many mapping while the cardinality of E* in a
unicast tunnel is generally one, therefore, in the form of one-to-
one mapping.
The set of tunnel egress-nodes for an original packet can be
determined either statically or dynamically. In a static manner,
the tunnel ingress node has a manually configured table or database
with which it determines the tunnel egress node for each
destination of the original xcast packet. In a dynamical manner,
the tunnel ingress node MAY use one of Neighbor Cache or Binding
Cache in IPv6 or Mobility binding list in IPv4. The table being
referenced when the tunnel ingress node determines the set of
tunnel egress-nodes is called xcast Tunneling Information
Base(XTIB), or simply Tunneling Information Base(TIB).
Jiwoong Lee Expire Feb 2003 [Page 3]
INTERNET-DRAFT Xcast Tunneling Aug 2002
There are two kinds of xcast tunneling. They are classified by the
type of encapsulating packet - Xcast or Unicast.
1.1. Xcast-in-Xcast encapsulation
In most cases, the original xcast packet is encapsulated within an
xcast packet addressed to the tunnel egress-nodes, and is sent to
inside of tunnel. Since both the original header and the tunnel
header are xcast headers, this is called X-in-X tunneling, which
means xcast encapsulation within xcast. The ingress node MAY
internally route and replicate the original packet in prior to
encapsulation. Inside the tunnel, the transit routers route the
received packet on the basis of information of the outermost header
only.
List of Addresses of the tunnel xcast packet is constructed as
follows:
- List of Addresses of the original packet is scanned in forward
manner, from the first address to the final one.
- Create a new blank list.
- The address of tunnel egress node for the scanned address is
appended to the new list.
- Repeat the previous step until all the addresses of List of
Addresses of the original packet are scanned.
The result list becomes List of Addresses of the tunnel packet.
This list has following characteristics:
- The number of the destination of newly generated list MUST be
equal to that of the address in List of Addresses of the
original header.
- Address duplication in List of Addresses is allowed in tunnel
destinations. That is, the same address MAY be listed several
times in List of Addresses.
At a decapsulating node, the bitmap of the tunnel xcast header MUST
be inherited to the bitmap of the original xcast header. Without
bitmap inheritance, a routing error might occur.
1.2. Xcast-in-Unicast encapsulation
Jiwoong Lee Expire Feb 2003 [Page 4]
INTERNET-DRAFT Xcast Tunneling Aug 2002
If the number of the tunnel egress-nodes is relatively small than
that of the destinations of the received xcast packet, it is
RECOMMENDED that the tunnel ingress node routes it and encapsulates
every original packet within a unicast packet addressed engaged
tunnel egress node. A tunnel egress node will receive a unicast
packet encapsulating an xcast packet. This is called X-in-U
tunneling, where U stands for unicast.
If there is no xcast router on the tunnel path, the tunnel ingress-
node SHOULD use X-in-U tunneling instead of X-in-X tunneling.
Otherwise it can convert the received xcast packet into multiple
unicast packets as many as the number of the destinations of the
received packet, and perform unicast tunneling, causing bandwidth
consumption on the delivery path and processing burden at the
tunnel ingress node simultaneously.
2. Terminology and semantics
2.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119[11].
In addition, this document frequently uses the following terms:
Xcast
Explicit Multicast. Defined in [1].
IP packet
An IP datagram. Defined in [2].
IP header
Header of an IP packet. Defined in [2].
Xcast packet
An IP datagram carrying xcast-specific routing information.
Xcast header
A set of xcast-specific routing information fields.
Destination of an IP packet
The address filled in Destination Address of an IP packet.
Destination(s) of an xcast packet
The set of destination(s) filled in List of Addresses of an
xcast packet.
Jiwoong Lee Expire Feb 2003 [Page 5]
INTERNET-DRAFT Xcast Tunneling Aug 2002
Encapsulation
Prepending separate routing information over a packet.
Decapsulation
Taking off the prepended routing information from the encapsu-
lated packet.
Original packet
A packet that undergoes encapsulation.
Original header
The header of an original packet.
Tunnel
A forwarding path identified by a pair of a encapsulating node
and a set of decapsulating nodes. The number of a set of
decapsulating nodes is a positive integer.
Tunnel end-node
A node where a tunnel begins or ends.
Tunnel ingress node
The tunnel end-node where an original packet is encapsulated.
Tunnel egress node
The tunnel end-node where decapsulation results in the
restoration of the original packet.
Tunnel branching-node
A node inside the tunnel where the tunnel branches off.
Tunnel packet
A packet that encapsulates an original packet.
Tunnel header
The header of a tunnel packet.
Tunnel IP packet
A tunnel packet as an IP packet.
Tunnel IP header
A tunnel header as an IP header.
Tunnel xcast packet
A tunnel packet as an xcast packet.
Tunnel xcast header
A tunnel header as an xcast header.
IPv6 main header
IPv6 header excluding Extension headers
Jiwoong Lee Expire Feb 2003 [Page 6]
INTERNET-DRAFT Xcast Tunneling Aug 2002
Xcast Tunneling Information Base (XTIB)
A kind of database or a table being referenced when the tunnel
ingress node determines the set of tunnel egress-nodes.
X-in-X
Xcast encapsulation within xcast packet.
X-in-U
Xcast encapsulation within Unicast packet.
2.2. Semantics
Some of the frequently-used expressions are stated clarifying their
meaning and usage.
- The source of an xcast packet is equal to the source of its IP
packet.
- An xcast packet is said to be addressed to (a set of)
destinations, which are listed in its List of Addresses.
- In general, the destination of an IP packet is different from
any destinations of the xcast packet carried in the IP packet.
3. Overview
This section overviews the protocol operations of X-in-X tunneling
and X-in-U tunneling with typical topology. Let [X,Y,Z] be a
notation to indicate a list of destination addresses of an xcast
packet. The bitmap of this packet, which is used for faster router
processing, is expressed as [#,#,#] where # is binary bit 1 or 0.
The bitmap is used to indicate active destinations in the list of
destination addresses of an xcast packet. For example, if an xcast
packet has bitmap of [0,1,0] while its list of destinations are
[X,Y,Z], the active list of destinations is expressed as [0,Y,0].
This result can be obtained by AND-like operation between the
bitmap and the list of destinations.
3.1. Xcast-in-Xcast tunneling
(Figure 1) briefly explains X-in-X tunneling protocol operations.
Assume A of (Figure 1) is a source sending xcast packets to
destinations F, G and H. B is the tunnel ingress node, and both D
and E are tunnel egress-nodes. C is a tunnel branching node at
somewhere in the tunnel. Note that the existence of C is virtual;
that is, C can be integrated into B or plural nodes on the path
simultaneously. Tunnel path is drawn with thick arrows. The
following letters after the colon in the figure means the
Jiwoong Lee Expire Feb 2003 [Page 7]
INTERNET-DRAFT Xcast Tunneling Aug 2002
destinations of the packet.
{1} {2} {3} {5}
+-------------+ +-------------+
| Xcast:D,E,E | | Xcast:D,0,0 |
+-------------+ +-------------+ +-------------+ +-------------+
| Xcast:F,G,H | | Xcast:F,G,H | | Xcast:F,G,H | | Xcast:F,0,0 |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
| | | |
| | v v
| | ++==========> D --------------> F
| | //
v v //
A ------------> B =============> C
\\ +-------------> G
\\ / ^
++==========> E |
^ \ |
| +-------------> H
| ^ |
| | |
+-------------+ | |
| Xcast:0,E,E | | | {6}
+-------------+ +-------------+
| Xcast:F,G,H | | Xcast:0,G,0 |
+-------------+ +-------------+
|
+-------------+
| Xcast:0,0,H |
+-------------+
{4} {7}
A: Source
F,G,H: Destinations
B: Tunnel ingress node
D,E: Tunnel egress nodes
C: Tunnel branching node
0: Zero-overwritten destination field (and its bitmap)
(Figure 1)
Example of X-in-X tunneling.
When A sends an xcast packet {1} addressed to the destinations F, G
and H, the packet reaches an xcast router B. As the tunnel ingress
node, B is configured to tunnel this incoming xcast packet by xcast
Jiwoong Lee Expire Feb 2003 [Page 8]
INTERNET-DRAFT Xcast Tunneling Aug 2002
encapsulation. Referring to its xcast Tunneling Information Base, B
finds out that the tunnel egress-nodes are D for destination F, and
E for destinations G and H. Consequently, B encapsulates {1} within
an xcast packet which is addressed to D,E and E, generating the
encapsulated packet {2}. Then B sends {2} into the tunnel.
Note that tunnel egress node E is duplicatively listed in the
tunnel header of {2}. Duplicate listing of destinations in an xcast
header is regarded syntactically legitimate and means more than one
destination are reachable via a single tunnel egress node. The
destination number of the tunnel xcast header is equal to that of
the original xcast header.
On receiving, C routes {2} on the basis of the tunnel header
information and generates two xcast packets {3}, {4}. They are
addressed to D,0,0 and 0,E,E respectively. "0" means that the
corresponding destination field and its bitmap are overwritten with
0, deactivating that destination at further processing.
When {3} arrives at D, D decapsulates {3} as a tunnel egress node
and obtains the original packet. Before any further processing, D
overwrites the bitmap of the original packet with that of the
tunnel packet - which is [1,0,0]. Therefore active destination list
of the packet to be sent is [F,0,0]. Now D sends {5} to the active
destination, F.
When {4} arrives at E, E decapsulates {4} as a tunnel egress node
and obtains the original packet. With the same procedure used for
{3} at D, E internally obtains the next packet:
+-------------+
| Xcast:0,G,H |
+-------------+
Routing this packet, E obtains {6} and {7} to be sent to two
destinations respectively.
3.2. Xcast-in-Unicast tunneling
(Figure 2) briefly explains X-in-U tunneling protocol operations.
Assume A of (Figure 2) is a source sending xcast packets to
destinations E, F and G. B is the tunnel ingress node, and both C
and D are tunnel egress-nodes. There is no tunnel branching node in
X-in-U tunnel, since an X-in-U tunnel always has only one tunnel
egress node. Tunnel path is drawn with thick arrows. 'Ucast' stands
for a unicast packet.
Jiwoong Lee Expire Feb 2003 [Page 9]
INTERNET-DRAFT Xcast Tunneling Aug 2002
{1} {2} {4}
+-------------+
| Ucast:C |
+-------------+ +-------------+ +-------------+
| Xcast:E,F,G | | Xcast:E,0,0 | | Xcast:E,0,0 |
+-------------+ +-------------+ +-------------+
| | |
| | |
| v v
| ++==========> C -------------> E
| //
v //
A -------------> B
\\ +------------> F
\\ / ^
++==========> D |
^ \ |
| +------------> G
| ^ |
| | |
+-------------+ | |
| Ucast:D | | | {5}
+-------------+ +-------------+
| Xcast:0,F,G | | Xcast:0,F,0 |
+-------------+ +-------------+
|
+-------------+
| Xcast:0,0,G |
+-------------+
{3} {6}
A: Source
E,F,G: Destinations
B: Tunnel ingress node
C,D: Tunnel egress nodes
0: Zero-overwritten destination field (and its bitmap)
(Figure 2)
Example of X-in-U tunneling.
(Figure 2) shows two X-in-U tunnels; one is between B and C, the
other is between B and D.
When A sends an xcast packet {1} addressed to the destinations F, G
and H, the packet reaches an xcast router B. As the tunnel ingress
node, B is configured to tunnel this incoming xcast packet by
unicast encapsulation. Referring to its xcast Tunneling Information
Base, B finds out that the tunnel egress-nodes are C for
destination E, and D for destinations F and G. Therefore, B
Jiwoong Lee Expire Feb 2003 [Page 10]
INTERNET-DRAFT Xcast Tunneling Aug 2002
internally routes {1} and generates two xcast packets according to
respective destination(s); they are as follows.
+-------------+ +-------------+
| Xcast:E,0,0 | | Xcast:0,F,G |
+-------------+ +-------------+
Now B encapsulates each of them within an unicast packet which is
addressed to C and D respectively, generating {2} and {3}.
When {2} arrives at C, C decapsulates {2} and generates {4} to be
sent to E.
When {3} arrives at D, D decapsulates {3} and internally obtains
the following packet:
+-------------+
| Xcast:0,F,G |
+-------------+
Routing this packet, D obtains {5} and {6} to be sent to F and G
respectively.
Following sections specify the detailed protocol operations for
encapsulation and decapsulation.
4. Encapsulation
4.1. Xcast-in-Xcast encapsulation
When an xcast packet is received by the tunnel ingress node, it
encapsulates the received packet within a tunnel xcast packet whose
payload is the original xcast packet, and sends the encapsulated
packet to the inside of the tunnel.
Since the original xcast packet is addressed to plural
destinations, the tunnel also has plural number of tunnel egress-
nodes. The number of the tunnel egress-nodes of a tunnel MUST be
equal to the number of destinations of the original packet.
Destinations of the tunnel packet, that is, the addresses of the
tunnel egress-nodes MAY be obtained by static or dynamical
reference to XTIB.
When the destinations of the tunnel packet is determined
statically, the tunnel ingress node SHOULD have a manually
configured Tunneling Information Base(TIB) beforehand. TIB is a
conceptual database or table satisfying following attributes:
Jiwoong Lee Expire Feb 2003 [Page 11]
INTERNET-DRAFT Xcast Tunneling Aug 2002
- The fist entry of TIB is the source address of the received
xcast packet.
- The second entry of TIB is the set of destination addresses of
the received xcast packet.
- The third entry of TIB is the set of destination addresses of
the tunnel xcast packet which encapsulates the received xcast
packet.
Otherwise, the tunnel ingress node MAY dynamically determine the
destinations of the tunnel packet. For example, the tunnel ingress
node MAY use Mobility binding list in IPv4 and Neighbor Cache or
Binding Cache in IPv6 to determine the tunnel egress-nodes.
In order to build an encapsulating xcast header, List of Addresses
of the tunnel packet MUST be constructed in following manner:
a. Create a new blank address list.
b. Look up the first destination of the original xcast packet.
c. Find out the address of tunnel egress node where to tunnel a
packet destined for the address which is found at the previous
step.
d. Append the result of step c to the list created in step a.
e. Look up the next destination of the original xcast packet.
f. Repeat steps from c to e until the steps for the final desti-
nation are done.
In the construction process of tunnel destinations, the number of
the destinations of the tunnel packet MUST be equal to that of the
original packet. Also the n-th destination of the tunnel packet
MUST have the legitimate binding relation with the n-th destination
of the original packet.
Note that the same addresses MAY be duplicatively listed as
destinations of the tunnel packet if two or more destinations of
the original packet share the same tunnel egress node.
Source Address of the tunnel packet MUST be the address assigned to
the tunnel ingress node.
The X bit of tunnel header MUST be set 1 in order to prevent
transit routers from performing X2U over the tunnel header. If
tunnel xcast packet undergoes X2U somewhere inside the tunnel, the
tunnel packet loses branching history and the tunnel egress node
will attempt to forward the original packet to every destination
Jiwoong Lee Expire Feb 2003 [Page 12]
INTERNET-DRAFT Xcast Tunneling Aug 2002
listed in the original packet, which may cause erroneously
duplicate deliveries of the packet.
Time To Live in IPv4 or Hop Limit in IPv6 of the tunnel packet
SHOULD be inherited from the original packet in order to prevent
possible routing loops which may cause infinite encapsulation over
packets.
The rest of packet structure is specified in following sub-
sections.
4.1.1. Message format in IPv4
To encapsulate a received xcast packet in IPv4, the tunnel ingress
node simply creates an xcast packet as follows:
IPv4 Source:
An address assigned to the tunnel ingress node. ingress node.
IPv4 Destination:
All_Xcast_Routers as defined in [1].
Time To Live:
Time To Live of the original packet.
Payload:
The original xcast packet.
Format for xcast header of tunnel packet is defined as follows;
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D|P|R| NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROT ID | LENGTH | RESV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Figure 3)
Tunnel xcast header format in IPv4
VERSION, A bit, R bit, NBR_OF_DEST, PROT ID, and CHANNEL IDENTIFIER
of the tunnel xcast packet inherit those from the original xcast
packet.
Jiwoong Lee Expire Feb 2003 [Page 13]
INTERNET-DRAFT Xcast Tunneling Aug 2002
X bit:
MUST be set to 1.
CHECKSUM:
A checksum over xcast header. The calculation rule is defined
in the section 9.2.2. of [1].
D bit and DSCPs SHOULD be assigned according to tunneling policy.
The tunnel xcast packet MAY inherit P bit and List of Port Numbers
of the original xcast packet if tunneling policy requires it.
List of Addresses:
List of addresses of tunnel egress nodes. This MAY be looked
up from the manually configured TIB or be dynamically built as
a result of construction process.
4.1.2. Message format in IPv6
To encapsulate a received xcast packet in IPv6, the tunnel ingress
node simply creates an xcast packet as follows:
IPv6 Source:
An address assigned to the tunnel ingress node.
IPv6 Destination:
All_Xcast_Routers as defined in [1].
Hop Limit:
Hop Limit of the original packet.
Payload:
The original xcast packet.
Formats for Routing extension header and Destination extension
header of the tunnel xcast packet are defined as follows;
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |RouteType=Xcast| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jiwoong Lee Expire Feb 2003 [Page 14]
INTERNET-DRAFT Xcast Tunneling Aug 2002
(Figure 4)
Tunnel Routing extension header format in IPv6
Next Header:
The next header defined in RFC 1700[10].
HdrExtLen:
8-bit unsigned integer. Length of the type Xcast Routing
extension header in 8-octet units, not including the first 8
octets.
RouteType, VERSION, A bit, R bit, NBR_OF_DEST, and CHANNEL
IDENTIFIER of the tunnel xcast packet inherit those from the
original xcast packet.
X bit:
MUST be set to 1.
D bit and DSCPs SHOULD be assigned according to tunneling policy.
List of Addresses:
List of addresses of tunnel egress nodes. This MAY be looked
up from the manually configured TIB or dynamically built as a
result of construction process.
If the original xcast packet carries type Ports Destination
Extension header, the tunnel xcast packet MAY include type Ports
Destination Extension header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Figure 5)
Tunnel Destination extension header in IPv6
Next Header:
The next header defined in RFC 1700[10].
HdrExtLen:
8-bit unsigned integer. Length of the type xcast Routing
extension header in 8-octet units, not including the first 8
octets.
Jiwoong Lee Expire Feb 2003 [Page 15]
INTERNET-DRAFT Xcast Tunneling Aug 2002
Opt Type:
Ports.
Opt Data Len:
Which is determined according to the rule defined in [1].
List of Port Numbers:
Which MAY be inherited from List of Port Numbers of the origi-
nal packet.
4.2. Xcast-in-Unicast encapsulation
Instead of Xcast-in-Xcast encapsulation, a tunnel ingress node MAY
tunnel incoming xcast packets by Xcast-in-Unicast tunneling. X-in-U
tunneling is appropriate when there is no xcast-capable router on
the tunnel path. Also X-in-U tunneling is more suitable than X-in-
X tunneling when there are many destinations for the original
packet while the number of the tunnel egress-nodes is small. If X-
in-X tunneling is used in this case, the tunnel packet will have
destinations (counting duplicates) as many as the number of the
destinations of the original packet, causing considerable
processing burden on tunnel transit routers. X-in-U MAY be used
also when only one tunnel egress node is available.
To tunnel xcast packets in X-in-U encapsulation, the tunnel ingress
node MUST route the packet first and generate xcast packets
addressed to destinations sharing the same tunnel egress node.
After this, the tunnel ingress node encapsulates each of newly
generated xcast packet in following manner:
IP Source:
An address assigned to the outgoing interface of the tunnel
ingress node.
IP Destination:
The address of the tunnel egress node.
Payload:
The newly generated xcast packet. By definition, this is the
original packet.
IP header options in IPv4 or IP extension headers in IPv6 of the
tunnel packet MAY be included according to the tunneling policy.
5. Decapsulation
5.1. Xcast-in-Xcast decapsulation
Jiwoong Lee Expire Feb 2003 [Page 16]
INTERNET-DRAFT Xcast Tunneling Aug 2002
On receiving an encapsulated xcast packet by means of X-in-X, the
bitmap of List of Addresses of the decapsulated original packet
MUST be overwritten with that of the tunnel packet before any
further processing.
After that, the tunnel egress node routes the original packet
according to its bitmap and List of Addresses.
5.2. Xcast-in-Unicast decapsulation
Tunnel egress node routes all the destinations of the original
packet after decapsulating the tunneled packet.
6. Transit node operations
6.1. Tunnel branching node operation
As an xcast router, a tunnel branching node simply routes any
incoming xcast packet based on its outermost xcast header, without
regard to its encapsulation level. The tunnel branching node MAY
NOT know whether it works as a tunnel branching node or not.
6.2. Nested Xcast tunneling
Nested tunneling is tunneling of a tunnel. Nested encapsulation is
an encapsulation over a tunnel packet. A transit node inside a
tunnel MAY encapsulate tunnel packets, if another transit node
inside that tunnel decapsulates them. A tunnel MUST NOT be laid
across another tunnel; that is, if required, only nested tunnel is
allowed. The outer tunnel end-nodes MAY not recognize the
existence of the inner tunnel(s).
7. Multicast-in-Xcast tunneling
xcast tunneling basically deals with tunneling mechanism of xcast
packets as inner ones. The specification for this is described in
section 3 to 6. This mechanism can be easily extended to support
tunneling of multicast packets within xcast encapsulation. This is
called Multicast-in-Xcast tunneling, in short, M-in-X tunneling.
M-in-X tunneling is an effective tunneling mechanism for multicast
packets. Traditionally, in order for multicast packets to be
tunneled, they are first replicated as many as the number of the
necessary tunnel egress-nodes, and then encapsulated within a
unicast packet addressed to respective tunnel egress node
(Multicast-in-Unicast tunneling, in short, M-in-U tunneling).
Inevitably this consumes both network bandwidth and processing
Jiwoong Lee Expire Feb 2003 [Page 17]
INTERNET-DRAFT Xcast Tunneling Aug 2002
overhead severely. M-in-X tunneling mitigates the resource
consumption.
As far as the tunnel egress-nodes are known, the tunnel ingress
node receives a multicast packet and encapsulate it within an xcast
packet, which is addressed to the tunnel egress-nodes. Even though
the transit nodes do not have multicast routing capability, or do
not have the appropriate multicast forwarding information base, if
they understand xcast routing, the M-in-X tunnel packet can be
delivered to every tunnel egress-nodes, with minimally consumed
network bandwidth and processing overhead at every involved node.
No bitmap inheritance is required at an egress node.
8. ICMP message processing
An error detected during the processing of a packet is reported to
the source of the packet, abiding by the general rules of
[0792/1112/2463]. Within the tunnel, an error is reported to the
tunnel ingress node.
8.1. Xcast-in-Xcast tunnel
Since the IP packet carrying xcast routing information is addressed
to a link local multicast address, an ICMP error message MUST NOT
be generated as a result of processing a packet inside the X-in-X
tunnel in IPv4.
In IPv6, an ICMPv6 error message MUST NOT be generated as a result
of processing a packet inside the X-in-X tunnel, with the exception
of following errors.
- Packet Too Big
- Parameter Problem
Note that RFC 0792 specifies that an ICMP error message includes
the original header and only the first 8 byte information following
the original header within the original packet. This implies that
an ICMP error message received by the ingress node from inside the
Xcast tunnel will carry the part of the outermost packet informa-
tion including the source address of the outermost packet and the
Channel Identifier of the outermost packet.
Only with the received ICMP error message, the ingress node cannot
identify the level of encapsulation; the packet that elicited an
ICMP error might be an unencapsulated packet. The only available
information that the ingress node can use in relaying the ICMP
error message to the source of the original packet is Channel
Jiwoong Lee Expire Feb 2003 [Page 18]
INTERNET-DRAFT Xcast Tunneling Aug 2002
Identifier of the outermost packet.
Therefore relaying ICMP error messages from the Xcast tunnel to the
original sender requires the management of tunnel soft state at the
tunnel ingress node.
8.2. Xcast-in-Unicast tunnel
Since an ICMP error message generated from inside the tunnel
includes only the tunnel header and the first 8 bytes of the IP
header of the original Xcast packet, it is not possible for the
ingress node to relay ICMP error messages to the original sender.
(No way to explicitly identify the address of the original sender.)
However, the ingress node MAY use the ICMP error occurred inside
the tunnel in managing the tunnel soft state.
9. Tunnel soft state management
This section is incomplete.
10. Security Considerations
The Xcast-in-Unicast encapsulation facilitate the operation of
IPsec[10]. The applying IPsec to the native Xcast packets may
cause the erroneous transport layer checksum. With Xcast-in-Unicast
encapsulation, this possible erroneous operation can be avoided
since the whole Xcast packet is dealt as the payload of the tunnel
packet.
CHANGES
This section briefly lists the changes in this draft relative to
the previous version of the document, draft-lee-xcast-
tunneling-00.txt
- The requirement level of Source Address of the tunnel packet
is relaxed.
- Limitation on Time To Live in IPv4 and Hop Limit in IPv6 is
placed in order to prevent possible routing loops.
- How to handle ICMP error messages received by the tunnel
ingress node is given.
Jiwoong Lee Expire Feb 2003 [Page 19]
INTERNET-DRAFT Xcast Tunneling Aug 2002
- Security consideration is added.
- Editorial corrections are given.
Reference
[1] R. Boivie, Y. Imai, W. Livens, D. Ooms, and O. Paridaens, Explicit
Multicast Basic Specification, IETF draft-ooms-xcast-basic-
spec-01.txt, March 2001
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
Sciences Institute, September 1981.
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.
[4] S. Deering, Host Extensions for IP Multicasting, RFC 1112, August
1989
[5] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[6] C. Perkins, "IP Encapsulation within IP", RFC 2003, October 1996
[7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[8] Conta, A. and S. Deering "Internet Control Message Protocol for the
Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[9] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 Specifica-
tion", RFC 2473, December 1998
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[11] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev-
els, RFC 2119, Mar 1997.
[12] Kent et al, "Security Architecture for the Internet Protocol", RFC
2401, November 1998.
Jiwoong Lee Expire Feb 2003 [Page 20]
INTERNET-DRAFT Xcast Tunneling Aug 2002
Author's Address
Jiwoong Lee
KTF Advanced Lab
1321-11 Seocho-Dong Seocho-Ku Seoul
Korea, Republic of
Phone : +82-2-3488-0416
Email : porce@ktf.com
Jiwoong Lee Expire Feb 2003 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 01:57:28 |