One document matched: draft-lee-xcast-reachability-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:57:29 |