INTERNET-DRAFT                                               Jiwoong Lee
Expires: Feb 2003                                                    KTF
                                                          13 August 2002



                  Explicit multicast reachability test
                  <draft-lee-xcast-reachability-00.txt>



Status of this memo


     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and working groups. Note that other
     groups may also distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsolete by other documents
     at anytime. It is inappropriate to use Internet Drafts as reference
     material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
                 http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft Shadow Directories can be accessed at
                      http://www.ietf.org/shadow.html.

     All remarks may be forwarded to author's email address or xcast
     IG(Incubation Group) mailing list: xcast@public.alcatel.com




Abstract

     It can be important to know which node has Explicit multicast
     receivability and routability before sending a large amount of data
     traffic in Explicit multicast. This document provides how to test
     the receivability and routability, in short, the reachability of
     Explicit multicast packets to a particular node.



1. Introduction

     Explicit multicast(xcast)[1], which is a new Internet multicast, is
     placed between IP unicasting and IP host group model multicasting




Jiwoong Lee                  Expire Feb 2003                   [Page 1]


INTERNET-DRAFT             Xcast Reachability                August 2002


     in the sense of morphology of packet structure and routing
     algorithm.  Xcast inherently does not provide signaling mechanism
     between two or more xcast nodes, therefore it lacks of 'HELLO'
     message as well, which could have been used to identify the
     presence of neighbors and their xcast ability - such as xcast
     receivability and xcast routability.

     Xcast basic specification, on the contrary, does provide neither
     'HELLO' message nor any other kind of signaling. And people
     affiliated with xcast does believe that designing and creating
     xcast-specific signaling might impair the excellence of xcast,
     which can be achieved by no signaling burden and no stateful
     feature.

     However, the features that can be provided by 'HELLO' stuff are
     still useful and sometimes regarded necessary; a sender node may
     wish to confirm that the intended destination node can receive and
     handle legitimate xcast packets before it starts to send a barrage
     of xcast data packets. Besides the sender node may wish to confirm
     that the transit network between itself and the receiver nodes can
     route and forward legitimate xcast packets before it starts to send
     a barrage of xcast data packets.

     To achieve those purposes this document specifies how to test a
     particular node's receivability and how to test a particular node's
     reachability which depends on xcast routability of each transit
     router, without newly creating or extending protocol operations.
     Instead, receivability / reachability test can be made heavily
     dependent on previously established protocol operations, especially
     including

     -    ICMP Destination Unreachable, Protocol Unreachable error mes-
          sage

     -    ICMP Destination Unreachable, Port Unreachable error message

     -    ICMP Time Exceeded, Time to live exceeded in transit error
          message

     -    Inference of packet discard in transit routers by timer expi-
          ration.




2. 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[7].

     In addition, this document frequently uses the following terms:




Jiwoong Lee                  Expire Feb 2003                   [Page 2]


INTERNET-DRAFT             Xcast Reachability                August 2002


     AXR  All_Xcast_Routers address

     MX   AXR-addressed xcast

     UX   Unicast-addressed xcast

     MX2U Conversion of MX into Unicast

     UX2U Conversion of UX into Unicast

     Xcast receivability
          Ability of a node with which it can receive an xcast packet
          and passes the payload to the subsequent upper layer handler.

     Xcast routability
          Ability of a node with which it can perform xcast routing over
          an incoming xcast packet and forward the packets produced as a
          result of the routing.

     Xcast reachability
          Ability of a transit network with which it can deliver the
          committed xcast packet to destination nodes. Xcast reachabil-
          ity refers to the ability of set of nodes while xcast
          routability refers especially to the ability of a particular
          node.

     Sender node
          Node which is supposed to send xcast data packets

     Receiver node
          Node which is supposed to receive xcast data packets

     Tester node
          Node from which the probe packet is generated.

     Testee node
          Node for which the probe packet is heading.

     Probe packet
          An experimental packet which travels from the tester node
          toward testee node. A probe packet may elicit ICMP error mes-
          sages from an unexpected node while traveling.



3. Test


3.1 Assumption of test operation

     The nodes on the traveling path of a probe packet MUST satisfy the
     following assumption.




Jiwoong Lee                  Expire Feb 2003                   [Page 3]


INTERNET-DRAFT             Xcast Reachability                August 2002


     -    All nodes are alive, that is, IP/ICMP sane.

     -    All transit nodes are capable of unicast routing

     -    All hosts are UDP sane.

     -    The sender node is able to generate xcast packets and is
          capable of xcast encapsulation, which is defined in [6].

     -    The receiver node, if it is able to receive xcast packets, is
          capable of xcast decapsulation, which is defined in [6].

     -    All xcast hosts that can legitimately handle MX packets also
          can handle UX packets.



3.2 Xcast receivability test

     A receiver node's xcast receivability MAY be tested before a sender
     node sends initial xcast data packets to it. With this end, a
     tester node (which is the sender node in most cases) sends a probe
     packet to the testee node (the receiver node).  The probe packet is
     essentially a UX packet carrying UDP header and its payload, while
     the Destination Port of UDP header is randomly given.

     Packet format of a probe packet MUST obey the following values:

     IP header

     Source Address:
          A unicast address assigned to the tester node

     Destination Address:
          A unicast address assigned to the testee node

     Protocol:
          PROTO_xcast.

     Xcast header

     X bit:
          MUST be set to 1.

     P bit:
          MAY be set to 1.

     NBR_OF_DEST:
          MUST be set to 1.

     PROT ID:
          MUST be set to 17. (indicating that the following header is




Jiwoong Lee                  Expire Feb 2003                   [Page 4]


INTERNET-DRAFT             Xcast Reachability                August 2002


          for UDP)

     Channel Identifier:
          Random number for identification purpose.

     List of Addresses:
          The same address as used in Destination Address in IP header

     List of Port Numbers:
          If P bit is set, this value MUST be the same as Destination
          Port of UDP header.

     UDP header

     Source Port:
          MAY be any number assigned by the tester node.

     Destination Port:
          33434 by default. MAY be changed by the testing configuration.

     Payload

          4 Byte random string for debug purpose.

     If the testee node does not have xcast receivability, the testee
     node does not recognize the Protocol number given in the IP header
     of the probe packet. Therefore, the testee node returns, on
     receiving the probe packet from the tester node, an ICMP
     Destination Unreachable, Protocol Unreachable error message to the
     tester node.

     Otherwise, the testee node does recognize the Protocol number given
     in the IP header of the probe packet. However, it does not
     recognize the given Destination Port number given in the UDP header
     since it mostly does not have an open socket for that Destination
     Port number. Therefore, the testee node returns, on receiving the
     probe packet from the tester node, and ICMP Destination
     Unreachable, Port Unreachable error message to the tester node.

     On receiving an ICMP error message elicited by the probe packet
     from the testee node, the tester node MUST check the TYPE and CODE
     of the ICMP error message. If TYPE and CODE indicates that the ICMP
     message is caused by Destination Unreachable, Protocol Unreachable
     problem, the tester node regards the testee node as not having
     xcast receivability. If TYPE and CODE indicates that the ICMP
     message is caused by Destination Unreachable, Port Unreachable
     problem, the tester node regards the testee node as having xcast
     receivability.

     There is a chance that the default UDP Destination port number used
     in the probe packet happens to be already being used on the testee
     node when the probe packet reaches it. In this case the tester node




Jiwoong Lee                  Expire Feb 2003                   [Page 5]


INTERNET-DRAFT             Xcast Reachability                August 2002


     can receive neither ICMP Destination Unreachable, Port Unreachable,
     nor ICMP Destination Unreachable, Protocol Unreachable on return.
     For a proper test, the UDP Destination port number SHOULD be
     changed.

     The Channel Identifier in the xcast header of the probe packet is
     used for the identification purpose that is to identify the probe
     packet causing a returned ICMP error message. This is useful when
     one application sends multiple probe packets to the same testee
     node before it receives any of ICMP error message on return, or
     when multiple application sends their own probe packets to the same
     testee node at the same tester node.

     X bit MUST be set to 1 since a transit router SHALL NOT perform
     UX2U over the probe packet.




3.3 Xcast reachability test

     Most xcast data packets are addressed to AXR address. The transit
     routers on the delivery path between the sender node and the
     receiver node MAY recognize any incoming packet as an xcast packet
     if it is addressed to AXR.

     Xcast reachability means the ability of transit routers placed
     between the sender node and the receiver node on the one-way
     delivery path. To be successful in the reachability test, all the
     transit routers MUST not discard the incoming packet only due to
     the fact that it is addressed to AXR and MUST be capable of xcast
     routing; if one or more transit routers are incapable of xcast
     routing, the test will fail. Xcast reachability test MAY be
     performed before a sender node sends xcast data packets to the
     receiver node, so as to confirm that the provided transit networks
     can deliver them to the receiver node successfully. With this end,
     the tester node (the sender node in most cases) sends one or more
     probe packets to the receiver node. The probe packet is essentially
     an AXR-addressed xcast packet carrying xcast receivability probe
     packet inside.

     Packet format of a probe packet MUST obey the following values:

     Tunnel IP Header

     Source address:
          A unicast address assigned to the tester node

     Destination address:
          All_Xcast_Routers.






Jiwoong Lee                  Expire Feb 2003                   [Page 6]


INTERNET-DRAFT             Xcast Reachability                August 2002


     Protocol:
          PROTO_Xcast.

     Tunnel xcast Header

     X bit:
          MUST be set to 1.

     P bit:
          MUST be set to 0.

     NBR_OF_DEST:
          MUST be set to 1.

     PROT ID:
          MUST be set to 4. (indicating that the following header is IP)

     Channel Identifier:
          Random number for identification purpose.

     List of Addresses:
          The same as Destination Address in original IP header.

     Original IP Header

     Source Address:
          A unicast address assigned to the tester node

     Destination Address:
          A unicast address assigned to the receiver node

     Protocol:
          PROTO_xcast

     IP options:
          The probe packet MUST NOT carry IP options; therefore the
          length of IP header of the probe packet is exactly 20 bytes in
          IPv4.

     Original xcast header

     X bit:
          MUST be set to 1

     P bit:
          MAY be set to 1.

     NBR_OF_DEST:
          MUST be set to 1

     PROT ID:
          MUST be set to 17. (indicating that the following header is




Jiwoong Lee                  Expire Feb 2003                   [Page 7]


INTERNET-DRAFT             Xcast Reachability                August 2002


          for UDP)

     Channel Identifier:
          Random number for identification purpose.

     List of Addresses:
          The same as Destination Address in the Original IP header

     List of Port Numbers:
          If P bit is set, this value MUST be the same as Destination
          Port of UDP header.

     UDP header

     Source Port:
          MAY be any number

     Destination Port
          33434 by default. MAY be changed by the testing configuration.

     Payload
          4 Byte random string for debug purpose.

     If all of the transit routers on the delivery path are capable of
     xcast routing and the testee node is xcast reachable, the probe
     packet will reach the intended receiver node successfully. On
     receiving the probe packet, the receiver node MUST decapsulate the
     probe packet and acquire the original packet, which is essentially
     a probe packet for xcast receivability test. Therefore, the
     receiver node will return an ICMP Destination Unreachable, Port
     Unreachable.

     If one of the transit routers on the delivery path is incapable of
     xcast routing or the testee node is not xcast-receivable, it MAY
     discard the incoming probe packet since the probe packet for
     testing xcast reachability is addressed to AXR, which is a link
     local multicast address. If it discards the incoming probe packet,
     it will keep silent with generating no ICMP error message as an
     indication of discard. If the tester node does not receive an ICMP
     error message as return of the probe packet for PROBE_TIMEOUT
     seconds, the reachability test SHOULD be regarded as failure.

     The failure of xcast reachability test means that at least one
     transit router on the one way delivery path between the tester node
     and the testee node is incapable of xcast routing or that the
     testee node itself is not xcast-receivable. It does not notify the
     tester node of which transit node is incapable of xcast routing.



4. Identifying the xcast routability of each node on the delivery path





Jiwoong Lee                  Expire Feb 2003                   [Page 8]


INTERNET-DRAFT             Xcast Reachability                August 2002


     This section describes not protocol specification, but possible
     extended applicability of protocol.

     Xcast routability test is a test of the Xcast routing ability of a
     particular transit node placed on the delivery path to a specified
     testee node. The purpose of xcast routability test is to determine
     how far a normal MX packet can reach without undergoing premature
     MX2U.

     The xcast routability of each node in the delivery path can be
     tested by adjusting Time-To-Live(TTL) value of the tunnel IP header
     of the probe packet during the xcast reachability test.

     As exactly in the same way as 'traceroute' uses, the tester node
     may increase TTL value of the probe packet from 1 until it finally
     gets a result of the xcast reachability test. Xcast reachability
     test has two kinds of results; one is an ICMP error message
     generated by the testee node, and the other is 'no message
     returned.' During the xcast routability test, the tester node will
     receive one or more ICMP error messages generated by the transit
     nodes before it finally obtains xcast reachability test result.
     Example scenario is given below.



                A ----- B ----- C ----- D ----- E
              tester                          testee



     Node A wishes to test xcast reachability to node E.


     1)   Node A sends the initial probe packet to E, with TTL = 1. Node
          B receives the initial probe packet and returns to node A an
          ICMP error message -  Time exceeded, time to live exceeded in
          transit. Thus, node A identifies the first hop node on the
          path leading to E is node B.

     2)   Node A sends the secondary probe packet to E, with TTL = 2.
          Assume node B is capable of xcast routing. Then node B will
          forward the probe packet to C. On receiving the probe packet,
          node C will return to node A an ICMP error message - Time
          exceeded, time to live exceeded in transit. When node A
          receives an ICMP error message from node C, it can identify
          the second hop node on the path leading to node B is node C,
          and the first hop node is capable of xcast routing. Otherwise
          node B will discard the probe packet without generating any
          ICMP error message. In this case node A will not receive any
          return message from the network for PROBE_TIMEOUT seconds.
          Since the xcast reachability test fails at the first hop node,
          node A can identify that node B is incapable of xcast routing.




Jiwoong Lee                  Expire Feb 2003                   [Page 9]


INTERNET-DRAFT             Xcast Reachability                August 2002


          Node E is not reachable from node A. No further probing is
          necessary.

     3)   Assume again that both node B, node C and node D are capable
          of xcast routing. Node A subsequently sends the probe packet
          to E, with TTL = 3. Node B and C forwards the probe packet
          toward node E, and node D will return an ICMP error message -
          Time exceeded, time to live exceeded in transit. Thus node A
          identifies the third node on the delivery path. Increasing one
          more TTL value will cause an ICMP error message - Time
          exceeded from node E, and additional TTL increment will elicit
          the result of xcast reachability test.

     In this way, the tester node can identify which node on the
     delivery path is capable or incapable of xcast routing.

     The Channel Identifier in the original xcast header of the probe
     packet is used for the identification purpose that is to identify
     the probe packet causing the ICMP error message. This is useful
     when one application sends multiple probe packets to the same
     testee node before it receives any of ICMP error message on return,
     or when multiple application sends their own probe packets to the
     same testee node.



5. List of default values


     PROBE_TIMEOUT
          5 by defaults. This value MAY be adjustable, preferably, by
          the command line interface.



6. Security considerations

     A probe packet does not contain any user-sensitive information
     within itself. However there is a possibility that a wicked node
     eavesdrops the probe packet and returns unsolicited ICMP error
     message to the origin of the probe packet, while one of the transit
     routers does discard and returns no error message. This can make
     the tester node misconstrue the result of xcast reachability and
     may trigger the sender node to start transmitting a barrage of user
     data packets.

     The reverse situation is also possible. A Man-in-the-Middle
     attacker can knowingly impede the progress of probe packet or the
     returning ICMP error message. This kind of attack can cause abrupt
     cessation of xcast transmission or blocking the commencement of
     xcast transmission from the beginning.





Jiwoong Lee                  Expire Feb 2003                  [Page 10]


INTERNET-DRAFT             Xcast Reachability                August 2002


References



[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 Control Message Protocol", STD 5, RFC 792,
     USC/Information Sciences Institute, September 1981.

[3]  Conta, A. and S. Deering "Internet Control Message Protocol for the
     Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.

[4]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
     October 1994.  See also: http://www.iana.org/numbers.html

[5]  F. Baker, "Requirements for IP Version 4 Routers", RFC1812, June
     1995.

[6]  J. Lee, Explicit Multicast Tunneling, IETF draft-lee-xcast-tunnel-
     ing-00.txt, Dec 2001

[7]  S. Bradner, Key words for use in RFCs to Indicate Requirement Lev-
     els, RFC 2119, Mar 1997.




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 11]