INTERNET-DRAFT Jiwoong Lee Expires: Feb 2003 KTF 09 August 2002 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(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]