|
Network Working Group Request for Comments: 3038 Category: Standards Track |
K. Nagami Y. Katsube Toshiba Corp. N. Demizu WaterSprings.ORG H. Esaki Univ. of Tokyo P. Doolan Ennovate Networks January 2001 |
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The Internet Society (2001). All Rights Reserved.
The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of Virtual Connection Identifier (VCID) is introduced to solve this problem. VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property.
Several label switching schemes have been proposed to integrate Layer 2 and Layer 3. The ATM Label Switching Router (ATM-LSR) is one of the major applications of label switching.
In the case of ATM VCs, the VPI and VCI labels are, in the general case, rewritten with new values at every switch node through which the VC passes and cannot be used to provide end to end identification of a VC.
In the context of MPLS 'stream', which are classes of packets that have some common characteristic that may be deduced by examination of the layer 3 header in the packets, are bound to layer 2 'labels'. We speak of stream being 'bound' to labels. These bindings are conveyed between peer LSRs by means of a Label Distribution Protocol [LDP].
In order to apply MPLS to ATM links, we need some way to identify ATM VCs in LDP mapping messages. An identifier called a Virtual Connection ID (VCID) is introduced. VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property.
The ATM has several types of VCs (transparent point-to-point link/VP/PVC/SVC). A transparent point-to-point link is defined as one that has the same VPI/VCI label at both ends of a VC. For example, two nodes are directly connected (i.e., without intervening ATM switches) or are connected through a VP with the same VPI value at both ends of the VP.
There are two broad categories of VCID notification procedures; inband and outband. The categorization refers to the connection over which the messages of the VCID notification procedure are forwarded. In the case of the inband procedures, those messages are forwarded over the VC to which they refer. In contrast the out of band procedures transmit the messages over some other connection (than the VC to which they refer).
We list below the various types of link and briefly mention the VCID notification procedures employed and the rational for that choice. The procedures themselves are discussed in detail in later sections.
Transparent point-to-point link : no VCID notification
VCID notification procedure is not necessary because the label
(i.e., VPI/VCI) is the same at each end of the VC.
VP : inband notification or VPID notification or no notification
- Inband notification
VCID notification is needed because the VPI at each end of the VC
may not be the same. Inband VCID notification is used in this
case.
- VPID notification
VCID notification is needed because the VPI at each end of the VC
may not be the same. VPID notification is used in this case.
- No notification
If a node has only one VP to a neighboring node, VCID notification
procedure is not mandatory. The VCI can be used as the VCID.
This is because the VCI value is the same at each end of the VP.
PVC : inband notification
Inband VCID notification is used in this case because the labels
at each end of the VC may not be the same.
SVC : there are three possibilities
- Outband notification
If a signaling message has a field which is large enough to carry
a VCID value (e.g., GIT [GIT]), then the VCID is carried directly
in it.
- Outband notification using a small-sized field
If a signaling message has a field which is not large enough to
carry a VCID value, this procedure is used.
- Inband notification
If a signaling message can not carry user information, this
procedure is used.
When an LSP is a point-to-multipoint VC and an ATM switch in an LSR is not capable of VC merge, it may cause problems in performance and quality of service. When the LSR wants to add a new leaf to the LSP, it needs to split the active LSP temporarily to send an inband notification message.
A VC has a directionality. The VCID procedure for a VC is always triggered from the upstream node of the VC, i.e., the upstream node notifies the downstream node of the VCID.
If bidirectional use of a label switched VC is allowed, the label switched VC is said to be bidirectional. In this case, two VCID procedures are taken, one for each direction.
If bidirectional use of a label switched VC is not allowed, the label switched VC is said to be unidirectional. In this case, only one VCID procedure is taken for the allowed direction.
VC directionality is communicated through LDP.
VCID notification is performed by transmitting a control message through the VC newly established (by signalling or management) for use as an label switched path (LSP). The procedure for VCID notification between two nodes A and B is detailed below.
PROPOSE message is unreliable. Once the 3-way handshake completes, the node B ignores all VCID PROPOSE messages received over the VC. The node B sends an LDP Mapping message, which contains the VCID value in the label TLV.
Node A Node B
| |
|--------------->| VCID PROPOSE
| |
|<---------------| VCID ACK
| |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mapping
Current LDP specification does not support multicast. But the VCID notification procedure is defined for future use. VCID notification is performed by sending a control message through the VC to be used as an LSP. The upstream node assigns the VCID value. The procedure by which it notifies the downstream node of that value is given below. The procedure is used when a new VC is created or a new leaf is added to the VC.
First, the procedure for establishing the first VC is described.
Upstream Downstream 1 Downstream 2
| | |
|-----------+--->| | VCID PROPOSE
| +------------------->|
| | |
|<---------------| |
| VCID ACK | |
|<-------------------------------| VCID ACK
Second, the procedure for adding a leaf to the existing point-to- multipoint VC is described.
This method can be applied when a VC is established using an ATM signaling message and the message has a field which is not large enough to carry a VCID value.
SETUP message of the ATM Forum UNI 3.1/4.0 has a 7-bit mandatory field for the user. This is a user specific field in the Layer 3 protocol field in the BLLI IE (Broadband Low Layer Information Information Element).
The BLLI value is used as a temporary identifier for a VC during a VCID notification procedure. This mechanism is defined as "Outband Notification using a small-sized field". The BLLI value of a new VC must not be assigned to other VCs during the procedure to avoid identifier conflict. When the association among the BLLI value, a
VCID value, and the corresponding VC is established, the BLLI value
can be reused for a new VC. VCID values can be assigned
independently from BLLI values.
Node A Node B
| |
|--------------->| ATM Signaling with BLLI
|<---------------|
| |
|--------------->| VCID PROPOSE with BLLI
| |
|<---------------| VCID ACK
| |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mapping
A point-to-multipoint VC can also be established using ADD_PARTY of the ATM Forum Signaling. ADD_PARTY adds a new VC leaf to an existing VC or an existing VC tree. In this procedure, the BLLI value of ADD_PARTY has to be the same value as that used to establish the first point-to-point VC of the tree. The same BLLI value can be used in different VC trees only when these VC trees can not add a leaf at the same time. As a result, the BLLI value used in the signaling must be determined by the root node of the multicast tree.
[note]
BLLI value is unique at the sender node. But BLLI value is not
unique at the receiver node because multiple sender nodes may
allocate the same BLLI value. So, the receiver node must
recognize BLLI value and the sender address. ATM Signaling
messages (SETUP and ADD_PARTY) carry both the BLLI and the sender
ATM address. The receiver node can realize which node sends the
BLLI message.
This subsection describes procedures for establishing a VC and for notification of its VCID between neighboring LSRs for unicast traffic.
The procedure employed when the upstream LSR assigns a VCID is as follows.
This subsection describes procedures for establishing the first VC for a multicast tree and for adding a new VC leaf to an existing VC tree including the notification of its VCID for a multicast stream using point-to-multipoint VCs.
In this procedure, an upstream LSR determines both the VCID and BLLI value in the multicast case. The reason that the BLLI value is determined by an upstream LSR is described above.
First, the procedure for establishing the first VC is described.
Second, the procedure for adding a leaf to the existing point-to- multipoint VC is described.
This method can be applied when a VC is established using a ATM signaling message and the message has a field (e.g., GIT [GIT]) which is large enough to carry a VCID value. Message format is described in [GIT]. After the VCID notification, the node A sends the LDP request message is sent to the node B. Then, the node B sends the LDP mapping message to the node A.
Node A Node B
| |
|--------------->| ATM signaling with VCID
|<---------------|
| |
|--------------->| LDP Label Request
| |
|<---------------| LDP Label Mapping
The approach that is used for the VCID notification procedure is also applicable to share the same identifier between both ends for a VP. VPID notification procedure is defined for this purpose.
A distinct VPID notification procedure is performed for each direction of each VP.
After the VPID notification is finished for a VP, a VCID of a VC in the VP is constructed with the VPID(MSB) and VCI(LSB) of the VC. The VCID can be used by LDP without performing VCID notification procedure. The message sequence is given below.
An LDP VCID message consists of the LDP [LDP] fixed header followed by one or more TLV. A VCID PROPOSE inband message and a VPID PROPOSE message are sent as a null encapsulation packet through a VC to be used as an LSP. There is only the label stack header before the LDP VCID PDU. A label value in the label stack entry [ENCAPS] for the VCID PROPOSE inband message and the VPID PROPOSE message are 4. Other messages are sent as TCP packets. This is the same as LDP.
The VCID message type field is as follows:
VCID Propose inband Message = 0x0501
VCID Propose Message = 0x0502
VCID ACK Message = 0x0503
VCID NACK Message = 0x0504
VPID Propose inband Message = 0x0505
VPID ACK Message = 0x0506
VPID NACK Message = 0x0507
This message is sent as a null encapsulation packet with LDP header and label stack header through a VC to be used as an LSP. The label value is 4. The reserved label value is required because the downstream node may receive this message after receiving the LDP
Label Request message in the case of point-to-multipoint VC. The downstream node must distinguish the VCID PROPOSE message from other messages and ignore the VCID PROPOSE message when the node already received the LDP Label Request message for the VC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|VCID Inband Propose (0x0501) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Id
Four octet integer used to identify this message.
Label TLV
Label TLV contains VCID value. Type of label TLV is VCID(0x0203).
An LSR uses the VCID PROPOSE message for the VCID notification procedure of the outband notification using a small-sized field. This message is sent through the VC for the LDP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| VCID Propose (0x0502) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Temporary ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
Four octet integer used to identify this message.
Label TLV
Label TLV contains VCID value. Type of label TLV is VCID(0x0203).
Temporary ID TLV
The value carried in the user specific field in the layer 3
protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0 Type of
label TLV is VCID temporary ID(0x0702).
An LSR send the VCID ACK message when the LSR accepts the VCID PROPOSE message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| VCID ACK (0x0503) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
Four octet integer used to identify this message.
Label TLV
The label TLV contains the VCID value of the received VCID PROPOSE
message. Type of label TLV is VCID(0x0203).
VCID Message ID
This value is the same as that of received VCID PROPOSE message.
An LSR send the VCID NACK message when the LSR does not accept the VCID PROPOSE message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| VCID NACK (0x0504) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
Four octet integer used to identify this message.
Label TLV
The label TLV contains the VCID value of the received VCID PROPOSE
message. Type of label TLV is VCID(0x0203).
VCID Message ID
This value is the same as that of received VCID PROPOSE message.
This message is sent as a null encapsulation packet with LDP header and label stack header through a VC to be used as an LSP. The label value is 4. The downstream node must distinguish the VPID PROPOSE message from other messages and ignore the VPID PROPOSE message when the node already received the LDP Label Request message for the VC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|VPID Inband Propose (0x0505) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Id
Four octet integer used to identify this message.
VPID TLV
VPID TLV contains VPID value. Type of label TLV is VPID(0x0703).
An LSR send the VPID ACK message when the LSR accepts the VPID PROPOSE message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| VPID ACK (0x0506) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
Four octet integer used to identify this message.
VPID TLV
The VPID TLV contains the VPID value of the received VPID PROPOSE
message.
VCID Message ID
This value is the same as that of received VCID PROPOSE message.
An LSR send the VPID NACK message when the LSR accepts the VPID PROPOSE message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| VPID NACK (0x0507) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
Four octet integer used to identify this message.
VPID TLV
The VPID TLV contains the VPID value of the received VPID PROPOSE
message.
VCID Message ID
This value is the same as that of received VCID PROPOSE message.
An LSR uses VCID Label TLV to encode labels for use on the link which does not have the same data link label at both ends of a VC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|VCID Label (0x0203) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VCID
This is 4 byte VCID value.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|VCID Message ID(0x0701) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCID Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VCID Message ID
This is 4 byte VCID Message ID
An LSR uses the VCID temporary ID TLV for the VCID notification procedure of the outband notification using a small-sized field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| VCID Temporary ID (0x0702)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Temporary ID |
+-+-+-+-+-+-+-+-+
Temporary ID:
The value carried in the user specific field in the layer 3
protocol field in the BLLI ID in the ATM Forum UNI 3.1/4.0
An LSR uses VPID TLV for the VPID notification procedure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| VPID (0x0703) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPID
This is 2 byte VPID value.
This document does not introduce new security issues other than those present in the LDP and may use the same mechanisms proposed for this technology.
The authors would like to acknowledge the valuable technical comments of Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, George Swallow and members of the LAST-WG of the WIDE Project.
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[GIT] Suzuki, M., "The Assignment of the Information Field and
Protocol Identifier in the Q.2941 Generic Identifier and
Q.2957 User-to-user Signaling for the Internet Protocol",
RFC 3033, January 2001.
[ENCAPS] Rosen, E., Viswanathan, A. and R. Callon, "MPLS Label Stack Encoding", RFC 3032, January 2001.
Ken-ichi Nagami
Computer & Network Development Center, Toshiba Corporation,
1, Toshiba-cho, Fuchu-shi,
Tokyo, 183-8511, Japan
Phone: +81-42-333-2884
EMail: ken.nagami@toshiba.co.jp
Noritoshi Demizu
WaterSprings.ORG
1-6-11-501, Honjo, Sumida-ku, Tokyo, 130-0004, Japan
EMail: demizu@dd.iij4u.or.jp
Hiroshi Esaki
Computer Center, University of Tokyo,
2-11-16 Yayoi, Bunkyo-ku,
Tokyo, 113-8658, Japan
Phone: +81-3-3812-1111
EMail: hiroshi@wide.ad.jp
Yasuhiro Katsube
Computer & Network Development Center, Toshiba Corporation,
1, Toshiba-cho, Fuchu-shi,
Tokyo, 183-8511, Japan
Phone: +81-42-333-2844
EMail: yasuhiro.katsube@toshiba.co.jp
Paul Doolan
Ennovate Networks
60 Codman Hill Road
Boxborough, MA
Phone: 978-263-2002 x103
EMail: pdoolan@ennovatenetworks.com
Copyright © The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.