INTERNET-DRAFT Jiwoong Lee Expires: Jun 2002 KTF 27 December 2001 Explicit Multicast Tunneling 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(Incuabtion Group) mailing list: xcast@public.alcatel.com Abstract Explicit multicast(Xcast)[1] is a new kind of Internet multicast, and 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 by the bitmap of the tunnel Xcast packet at tunnel egress-nodes, in order to control the active destination set. Table of Contents Jiwoong Lee Expire Jun 2002 [Page 1] INTERNET-DRAFT Xcast Tunneling Dec 2001 Status of this memo . . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . 12 4.1.2. Message format in IPv6 . . . . . . . . . . . . . . . . . . . 13 4.2. Xcast-in-Unicast encapsulation . . . . . . . . . . . . . . . . 15 5. Decapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Xcast-in-Xcast decapsulation . . . . . . . . . . . . . . . . . 16 5.2. Xcast-in-Unicast decapsulation . . . . . . . . . . . . . . . . 16 6. Transit node operations . . . . . . . . . . . . . . . . . . . . . 16 6.1. Tunnel branching node operation . . . . . . . . . . . . . . . . 16 6.2. Nested Xcast tunneling . . . . . . . . . . . . . . . . . . . . 17 7. Multicast-in-Xcast tunneling . . . . . . . . . . . . . . . . . . 17 8. ICMP message processing . . . . . . . . . . . . . . . . . . . . . 17 8.1. Xcast-in-Xcast tunnel . . . . . . . . . . . . . . . . . . . . . 18 8.2. Xcast-in-Unicast tunnel . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 18 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Jiwoong Lee Expire Jun 2002 [Page 2] INTERNET-DRAFT Xcast Tunneling Dec 2001 This document speficies generic mechnism by which an Explicit multicast(Xcast) packet is encapsulated and decapsulated. An Xcast packet can be encapsulated within one of Explicit multicast, unicast or host group model multicast packet. The main goal of the encapsulation is tunneling a packet. 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 engaged 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 (Xcast)[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 thoes of unicast packet tunneling. When an Xcast packet is received by a tunnel ingress-node, the ingress-node encapsulates it within one of 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-node 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 statical 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). There are two kinds of Xcast tunneling. They are classified by the Jiwoong Lee Expire Jun 2002 [Page 3] INTERNET-DRAFT Xcast Tunneling Dec 2001 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. 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 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 is the list of destination of the tunnel packet. This list has following characteristics: - The number of the destination of newly generated list should 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 a 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 If the number of the tunnel egress-nodes is small relatively than the 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 Jiwoong Lee Expire Jun 2002 [Page 4] INTERNET-DRAFT Xcast Tunneling Dec 2001 tunnel egress-node. A tunnel egress-node will receive the unicast packet encapsulating Xcast one. 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[2119]. In addition, this document frequently uses the following terms: Xcast Explicit Multicast. Defined in [1] IP packet An IP dagagram. 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 the destination field of an IP packet. Destination(s) of an Xcast packet The set of destination(s) filled in the List of Addresses of an Xcast packet. Encapsulation Prepending separate routing informaiton over a packet. Decapsulation Taking off the prepended routing information from the Jiwoong Lee Expire Jun 2002 [Page 5] INTERNET-DRAFT Xcast Tunneling Dec 2001 encapsulated packet. Original packet A packet that ungergoes 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 MAY be one. 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 Xcast Tunneling Information Base (XTIB) A database or a table being referenced when the tunnel ingress-node determines the set of tunnel egress-nodes. Jiwoong Lee Expire Jun 2002 [Page 6] INTERNET-DRAFT Xcast Tunneling Dec 2001 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 describes the protocol operations of X-in-X tunneling and X-in-U tunneling with typical topologies. 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 by [#,#,#] where # is a 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. Tunnel path is drawn with thick arrows. The following letters after the colon in the figure means the destinations of the packet. {1} {2} {3} {5} +-------------+ +-------------+ | Xcast:D,E,E | | Xcast:D,0,0 | Jiwoong Lee Expire Jun 2002 [Page 7] INTERNET-DRAFT Xcast Tunneling Dec 2001 +-------------+ +-------------+ +-------------+ +-------------+ | 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 encapsulation. Refering 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 duplicately listed in the tunnel Jiwoong Lee Expire Jun 2002 [Page 8] INTERNET-DRAFT Xcast Tunneling Dec 2001 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 interanlly 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. {1} {2} {4} +-------------+ | Ucast:C | +-------------+ +-------------+ +-------------+ | Xcast:E,F,G | | Xcast:E,0,0 | | Xcast:E,0,0 | +-------------+ +-------------+ +-------------+ | | | | | | Jiwoong Lee Expire Jun 2002 [Page 9] INTERNET-DRAFT Xcast Tunneling Dec 2001 | 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. Refereing 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 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 | +-------------+ +-------------+ Jiwoong Lee Expire Jun 2002 [Page 10] INTERNET-DRAFT Xcast Tunneling Dec 2001 Now B encapsulates each of them within an unicast packet which is addressed to C and D respectively, generating {2} and {3}. When {2} arrvies 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 statical 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: - 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 or 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 Jiwoong Lee Expire Jun 2002 [Page 11] INTERNET-DRAFT Xcast Tunneling Dec 2001 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, the 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 to 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. With 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. The source of the tunnel packet MUST be the address belonging to the outgoing interface of 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 listed in the original packet, which may cause erroneously duplicate deliveries of the packet. Rest of packet structure is specified in following sub-sections. Jiwoong Lee Expire Jun 2002 [Page 12] INTERNET-DRAFT Xcast Tunneling Dec 2001 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 outgoing interface of the tunnel ingress-node. IPv4 Destination: All_Xcast_Routers as defined in [1] Paylaod: 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, PROTO ID, and CHANNEL IDENTIFIER of the tunnel Xcast packet inherit those from the original Xcast packet. 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. Jiwoong Lee Expire Jun 2002 [Page 13] INTERNET-DRAFT Xcast Tunneling Dec 2001 List of Addresses: List of addresses of tunnel exit-point nodes. This MAY be looked up from the manually configured TIB or dynamically built as a result of construction process. 4.1.2. Message format in IPv6 To encapsulate a received Xcast packet in IPv4, the tunnel ingress- node simply creates an Xcast packet as follows: IPv6 Source: An address assigned to the outgoing interface of the tunnel ingress-node. IPv6 Destination: All_Xcast_Routers as defined in [1] Paylaod: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Figure 4) Tunnel Routing extension header in IPv6 Next Header: The next header value according to [7] from the Assigned Num- bers RFC [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 Jiwoong Lee Expire Jun 2002 [Page 14] INTERNET-DRAFT Xcast Tunneling Dec 2001 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 exit-point 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 value according to [7] from the Assigned Num- bers RFC [10]. HdrExtLen: 8-bit unsigned integer. Length of the type Xcast Routing extension header in 8-octet units, not including the first 8 octets. Opt Type: Ports. Opt Data Len: Which is determined according to the rule defined in [1] List of Port Numbers: Which is inherited from List of Port Numbers of the original packet. Jiwoong Lee Expire Jun 2002 [Page 15] INTERNET-DRAFT Xcast Tunneling Dec 2001 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 by 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. Paylaod: The newly generated Xcast packet. By definition, this is an original packet. IP header options in IPv4 or IP extension headers in IPv6 of the tunnel packet MAY be included accroding to the tunneling policy. 5. Decapsulation 5.1. Xcast-in-Xcast decapsulation 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 by that of the tunnel packet before any further processing. After that, the tunnel egress-node routes the original packet according to its bitmap. 5.2. Xcast-in-Unicast decapsulation Jiwoong Lee Expire Jun 2002 [Page 16] INTERNET-DRAFT Xcast Tunneling Dec 2001 Tunnel egress-node routes all the destinations of the original packet after decapsulatin 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 wheter 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 overhead severely. M-in-X tunneling mitigates just stated 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. Jiwoong Lee Expire Jun 2002 [Page 17] INTERNET-DRAFT Xcast Tunneling Dec 2001 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 error - Packet Too Big - Parameter Problem 8.2. Xcast-in-Unicast tunnel An ICMP error message handling in IPv4 X-in-U tunnel, section 4 of [6] is obeyed. An ICMPv6 error message handling in IPv6 X-in-U tunnel, section 8 of [9] is obeyed. This sub-section is incomplete. 9. Security Considerations This section is incomplete. Reference Jiwoong Lee Expire Jun 2002 [Page 18] INTERNET-DRAFT Xcast Tunneling Dec 2001 [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 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 Jun 2002 [Page 19]