Network Working Group Thomas D. Nadeau
Internet Draft Monique Morrow
Expires: April 2004 Cisco Systems, Inc.
Editors
October 2003
Pseudo Wire (PW) OAM Message Mapping
draft-nadeau-pwe3-oam-msg-map-02.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 its 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 obsoleted by other
documents at any time. 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.
Copyright (C) The Internet Society (2001). All rights
reserved.
Abstract
This document enumerates the OAM message mapping from pseudo
wire emulated edge-to-edge services over MPLS and IP transport
networks to their native attached services.
Table of Contents
Abstract
1. Scope....................................................2
2. Terminology..............................................2
3. Introduction.............................................3
4. Overview of ATM and Frame Relay Management functions.....7
5. Like-to-Like Scenarios..................................10
6. L2TPv3 Message Mapping..................................11
7. Ethernet Interworking Mapping...........................11
8. VPLS....................................................11
9. Security Considerations.................................11
10. Intellectual Property Rights Notices...................14
11. Full Copyright Statement...............................14
12. Contributors...........................................15
1. Scope
L2TPV3 OAM message mapping will be added to this document in a
future version. OAM message mapping related to Ethernet
interworking will be added to this document in a future version.
2. Terminology
AIS Alarm Indication Signal
AOM Administration, Operation and Maintenance
CC Continuity Check
CE Customer Edge
CPCS Common Part Convergence Sublayer
FRBS Frame Relay Bearer Service
IWF Interworking Function
LB Loopback
NE Network Element
OAM Operations and Maintenance
PE Provider Edge
PW Pseudowire
PSN Packet Service Node
RDI Remote Defect Indicator
SDU Service Data Unit
VCC Virtual Channel Connection
VPC Virtual Path Connection
3. Introduction
This document describes the mapping to/from of faults detected
in pseudo-wires carrying emulated services to OAM messages
native to those services. This includes multiple networks
involving ATM, MPLS, IP and Frame-Relay either in a like-to-
like (ATM-MPLS-ATM) or an interworking configuration (i.e: FR-
MPLS-ATM). While management interworking is well defined for
ATM/Frame Relay [FRF.8.1, ITU-T I.555], the mapping of PW
failures to the equivalent ATM/Frame Relay OAM messages when
pseudo wires are used to interconnect these technologies is
not well defined.
For example, in the case of ATM like-to-like pseudowire, the
transport of OAM cells depends on the defined modes, but
interworking with packet services node failures is not
defined. A summary of these modes and OAM transport
capabilities will be shown TBD.
Since local OAM termination interpretation and reporting is in
some cases optional, certain failures may be detected by the
customer edge without the knowledge of the carrier.
|<--ATM-->| |<-MPLS-->| |<-ATM->|
| | | | | |
ATMv v ATM v v ATM v V
ATM UNI UNI UNI UNI
+----+ | | | NNI | | NNI | | | +----+
|ATM |----|..................| |................|---|ATM |
| CPE| | | | | | | | | |CPE |
| |----|..................| |................|---| |
+----+ | | | | | | | | +----+
Customer^ ^Customer
Edge 1| <-ATMoMPLS-> | Edge 2
|<-----------ATM PVC----------->|<-----ATM PVC------>|
Figure 1 ATM Like-to-Like over MPLS
The mapping of MPLS data-plane failures can also be useful in
some deployment scenarios where the provider edge terminates
OAM messages and no means are defined to transport them across
the pseudowire, management interworking will be lost. Such an
application exists when transporting services over MPLS in an
any-to-any interworking configuration. This involves two
provider edge devices interconnected by a pseudowire using
MPLS as a transport. One provider edge might terminate a Frame
Relay service and another provider edge terminates an ATM
service. In this case Frame Relay and ATM OAM is terminated
locally without transport over the pseudo-wire. Thus a data-
plane failure in the pseudowire is neither detected nor
reported to the ATM/Frame Relay networks which view the pseudo-
wire as if it were a native interface. For more details on
this application please see [SAJASSI]. Even though this
application has some merits as described in the aforementioned
draft, the lack of management interworking is a major
drawback. However, with the introduction of LSP ping
[LSPPING], VCCV [VCCV] and additional techniques described
herein, it is possible to retain native OAM message mechanisms
when using a packet switched network as described in [PWEARCH].
The following figures are provided to illustrate the above
point.
|<--FR-->| |<-ATM->|
| | | |
FR v v FR IWF ATM v v ATM
UNI UNI +----+ UNI UNI
+----+ | | | NNI | | NNI | | | +---+
| FR |---|......... ........| |...................|---|ATM |
| CPE| | | | | | | | | |CPE |
| |---|..................| |...................|---| |
+----+ | | | | | | | | +----+
Customer^ +----+ ^Customer
Edge 1| | Edge 2
|<---------FR PVC-------->| |<------- ATM PVC------>|
| | | |
|<-Q933-><-Q933-> <-Q933->| |<- F5/F4 end to end -->|
| <------------| |---------------------->|
| Interworking Q933| |Interworking OAM cells |
| | | |
| | | --------->|
| | | AIS |
| | |<----------------------|
| | | RDI |
| | |<--------------------->|
| | | CC |
| | | |
|------------------------>| |---------------------->|
|<------------------------v |<----------------------v
Loopback (ITU-T I.620) Loopback
Figure 2: Basic Frame Relay/ATM interworking without
IP/MPLS
F4 flows transpire between network elements and are used within
virtual paths to report an unavailable path or virtual path that cannot
be guaranteed. F5 flows transpire between network elements used within
virtual connections to report degraded virtual channel performance such
as late arriving cells, lost cells and cell insertion problems.
Both F4 and F5 flows can be configured as either end-to-end or
segment-loopback and used with an alarm indication signal (AIS)
and remote defect indication (RDI) functions.
Frame Relay/ATM IWF is performed at one of the provider edges,
and management interworking is transported/extended across the
Frame Relay pseudowire. Figure 3 is an example of Frame Relay
extended across the MPLS network.
|<--FR-->| |<-MPLS-->| |<-ATM->|
| | | | | |
FR V v FR v v ATM v V ATM
UNI UNI UNI UNI
+----+ | | | NNI | | NNI | | | +----+
| FR |---|......... ........| |................|---|ATM |
| CPE| | | | | | | | | |CPE |
| |---|..................| |................|---| |
+----+ | | | | | | | | +----+
Customer^ ^Customer
Edge1| <-FRoMPLS-> |Edge2
|<-----------FR PVC------------>|<-----ATM PVC------>|
Figure 3 FR/ATM interworking with IP
Frame Relay/ATM Interworking function is performed at one of
the provider edges and management interworking is transported
and extended across the Frame Relay pseudowire. Figure 4
depicts ATM extended across the MPLS network
|<--FR-->| |<-MPLS->| |<-ATM->|
| | | | | |
FR V v FR v v ATM v V ATM
UNI UNI UNI UNI
+----+ | | NNI | | NNI | | | +----+
| FR |-|......... ........| |................|---|ATM |
| CPE| | | | | | | | | |CPE |
| |-|..................| |................|---| |
+----+ | | | | | | | | +----+
Customer^ ^Customer
Edge 1 | <ATMoMPLS-> | Edge 2
|<-----------FR PVC--->|<--------ATM PVC----->|
Figure 4: Frame Relay/ATM Interworking with IP/MPLS
Frame Relay/ATM Interworking function is performed at one of
the provider edges and management interworking is transported
and extended across the ATM pseudowire.
When extending Frame Relay or ATM across the MPLS network, the
mapping of OAM functionality between ATM and Frame Relay is
the same as in the basic Frame Relay/ATM interworking without
ATM case. Nevertheless, in the MPLS cloud, when Frame Relay
(resp. ATM) extends across the MPLS network it is necessary to
define Frame Relay OAM (resp. ATM OAM) mapping to MPLS OAM on
this "segment". In Figure 5 MPLS OAM is performed by MPLS LSP
PING and Tunnel trace functions.
|<FR>| |<-MPLS->| |<ATM>|
| | | | | |
FR v v FR v v ATM v vATM
UNI UNI UNI UNI
+---+ | | | NNI| | NNI | | | +----+
|FR |---|..............| |.................|---|ATM |
|CPE| | | | | | | | | |CPE |
| |---|..............| |.................|---| |
+---+ | | | | | | | | +----+
Cust^ ^Cust
Edge1| |Edge2
|<----FR PVC----> |<MPLS> |<----ATM PVC-------->|
| | | |
|<Q933,Q933,Q933> |<MPLSOAM>|< F5/F4 end to end> |
| <------------ | |-------------------->|
|InterworkingQ933 | |Interworking OAM cell|
| | | |
| | | ---------> |
| | | AIS |
| | |<--------------------|
| | | RDI |
| | |<------------------->|
| | | CC |
| | | |
|---------------> | |-------------------->|
|<--------------- | |<--------------------|
Loopback (ITU-T I.620) Loopback
Figure 5: FR/ATM interworking with IP/MPLS
4. Overview of ATM and Frame Relay Management functions
4.1. Frame Relay Management
The management of Frame Relay Bearer Service (FRBS)[ITU-T
I.555] connections can be accomplished through two distinct
methodologies:
1. Based on ITU-T Q.933 Annex A, Link Integrity Verification
procedure, where STATUS and STATUS ENQUIRY signaling messages
are sent using DLCI=0 over a given UNI and NNI physical link.
[ITU-T Q.933]
2. Based on FRBS LMI, and similar to ATM ILMI where LMI is
common in private Frame Relay networks.
In addition, ITU-T I.620 addresses Frame Relay loopback, but
the deployment of this standard is relatively limited. [ITU-T
I.620]
It is possible to use either, or both, of the above options to
manage Frame Relay interfaces. However, from the perspective
of ATM/Frame Relay interworking, Q.933 messages are used and
mapped to the corresponding ATM OAM when possible.
The status of any provisioned Frame Relay PVC may be updated
through:
STATUS messages in response to STATUS ENQUIRY messages, these
are mandatory. Optional unsolicited STATUS updates independent
of STATUS ENQUIRY (typically under the control of management
system, these updates can be sent periodically (continuous
monitoring) or only upon detection of specific defects based
on configuration.
Note that in contrast to ATM, monitoring the status of Frame
Relay PVC end-to-end requires coordination with management
systems since Q.933 messages are link-to-link between nodes.
Frame Relay/ATM management interworking is defined in [FRF.8.1]
and [ITU-T I.555].
4.2. ATM management
ATM management and OAM mechanisms are much more evolved than
those of Frame Relay. There are five broad management-related
categories, including fault management (FT), Performance
management (PM), configuration management (CM), Accounting
management (AC), and Security management (SM). ITU-T
Recommendation I.610 describes the functions for the operation
and maintenance of the physical layer and the ATM layer, that
is, management at the bit and cell levels. The document scope
is to focus on fault management interworking between Frame
Relay, ATM and MPLS, we will therefore concentrate on ATM
fault management functions. [ITU-T I.610] Fault management
functions include the following:
1) Alarm indication signal (AIS)
2) Remote Defect indication (RDI).
3) Continuity check (CC).
4) Loopback (LB)
Some of the basic ATM fault management functions are described
as follows:
Alarm indication signal (AIS) sends a message in the same
direction as that of the signal, to the effect that an error
has been detected.
Remote defect indication (RDI) sends a message to the
transmitting terminal that an error has been detected. RDI is
also referred to as the far-end reporting failure. Alarms
related to the physical layer are indicated using path
AIS/RDI. Virtual path AIS/RDI and virtual channel AIS/RDI are
also generated for the ATM layer.
OAM cells (F4 and F5 cells) are used for the control of
virtual paths and virtual channels with regard to their
performance and availability. F4 cells are used to monitor a
VPC, F5 cells for a VCC. OAM cells in the F4 and F5 flows are
used for monitoring a segment of the network and end-to-end
monitoring. OAM cells in F4 flows have the same VPI as that of
the connection being monitored. OAM cells in F5 flows have the
same VCI as that of the connection being monitored. The AIS
and RDI messages of the F4 and F5 flows are sent to the other
network nodes via the VPC or the VCC to which the message
refers. The type of error and its location can be indicated in
the OAM cells. Continuity check is another fault management
function. To check whether a VCC that has been idle for a
period of time is still functioning, the network elements can
send continuity-check cells along that VCC.
Please note that in Frame Relay/ATM service interworking
specified in FRF.8.1 and ITU-T I.555 only some of the above
functions are mapped, but not loopback. Other functions are
not simple to map due to lack of equivalent procedures and
functions.
4.3. Mapping of Management Messages
In general, fault management interworking between Frame Relay
and ATM may be summarized as down to STATUS "up" or "down" on
the frame relay side and AIS on the ATM side. Although on the
ATM side fault management and localization is much more
advanced than that of Frame Relay, at the service interworking
level the limitation is the least common denominator (FR). In
cases where OAM is terminated at the PEs and the PW is not
capable of transporting OAM VCCV[VCCV] proposes a mechanism
that supports this function.
4.4. Mapping of MPLS data-plane failures
[VCCV] specifies the use of procedures defined in [BFD] (asynchronous
mode) for PW failure detection. This paragraph specifies how to map
BFD diagnostics to Frame Relay and ATM failure notifications.
[BFD] specifies that PEs periodically send control messages to verify
the status of the PW. The PEs negotiate the transmission interval to
be used.
When the downstream PE (PE2) doesn't receive control messages from the
upstream PE (PE1) during a certain number of transmission intervals
(a number provisioned by the operator), or if it determines in another
way that communication is lost, it declares that the PW in the
direction from PE1 to PE2 is down. It stores the cause (e.g. "control
detection time expired") and sends a message to PE1 with H=0 (i.e. "I
don't hear you"). In turn, PE1 declares the PW in the direction from
PE1 to PE2 down and stores as cause: "neighbor signaled session down".
Depending on the emulated services, PE2 may send a FDI indication on
its attachment circuits and PE1 may send an RDI indication on its
attachment circuits.
BFD defines the following diagnostics:
0 -- No Diagnostic
1 -- Control Detection Time Expired
2 -- Echo Function Failed
3 -- Neighbor Signaled Session Down
4 -- Forwarding Plane Reset (Local equipment failure)
5 -- Path Down (Alarm Suppression)
6 -- Concatenated Path Down (Propagating access link alarm)
7 -- Administratively Down
Of these, 0 is used when the PW is up and 2 is not applicable to
asynchronous mode. 6 is discussed in sections 4.6 and 4.9. The rest are
mapped as follows:
RDI 3
FDI 1, 4, 5, 7
For ATM attachment circuits, Alarm Indication Signal (AIS) is used for
failure notification in the forward direction and Remote Defect
Indication (RDI) in the reverse direction. For Frame Relay attachment
circuits, STATUS messages are used both in forward and backward
directions.
4.5. Mapping of ATM PVC management procedures
In this section it is assumed that both Frame Relay and MPLS
networks are in working order, and the problem is initiated
from the ATM network.
The fault management functions considered include:
1) AIS/RDI OAM cells
2) End-to-end CC cells, if this option is supported.
3) Loopback cells, under System Management control.
For items 1 and 2, these fault conditions should trigger PW
tear down without the involvement of MPLS ping.
However, Loopback may be used to initiate automatic MPLS Ping.
Each of the above conditions is discussed below.
4.6. Mapping of AIS/RDI
In case a failure on an ATM attachment circuit leads to AIS and RDI,
the PE shall send a BFD control message with diagnostics code 6:
Concatenated Path Down (Propagating access link alarm). The
downstream PE shall translate this into a STATUS message indicating
that the DLC is inactive.
Recovery from the AIS state is initiated by one of the
following conditions:
1. No AIS/RDI Cells are received for 2.5+ - 0.5 sec, while no
user-data or CC cells are received during the period. [ITU-T,
I.610]
2. User-data cells are received.
3. CC cells are received.
After recovery on the ATM side, the PE shall start sending control
messages with diagnostics code 0 - "No Diagnostic". PE at the FR
side must send "active" STATUS messages for the corresponding DLCIs.
4.7. Mapping of Continuity Check
Continuity check, if supported, can be mapped as described in
the AIS/RDI case. In this case, the absence of CC cells or
user data cells for the specified period (3.5 + - 0.5 sec
nominally) indicates the ATM PVC is "down" [ITU-T I.610].
4.8. Mapping of Loopback
Loopback procedure is typically initiated under the control of
NE Management system or the end user management system for in-
service or pre-service connectivity verification and fault
localization. The ATM PVC is considered inactive if loopback
test is unsuccessful, i.e. cells are not received back to the
originating point within 5 seconds (nominally). The mapping of
LB tests on the ATM side to Frame Relay side is not typically
done since I.620 (Frame Relay loopback) is not widely
deployed. However, in FRF.8.1, unsuccessful LB tests are
mapped into STATUS inactive for the corresponding FR DLCI(s).
Thus, similar functionality can be achieved, iif the PE indicates
error conditions on the attachment circuit in the BFD control
messages.
Some potential improvements can be achieved if ATM LB test
happens to be successful, but the PE at the ATM side uses the
LB test to trigger automatic MPLS ping. In this case, if we
assume that the ATM network is functional but there is a
problem in the MPLS data-plane, then invoking ATM LB test will
result in successful LB, but the PE at the ATM side will
generate AIS if the MPLS ping fails.
4.9. Mapping of Frame Relay PVC management procedures
In case a failure on a Frame Relay attachment circuit leads STATUS
messages indicating that the DLC is inactive, the PE shall send a BFD
control message bfd with diagnostics code 6: "Concatenated Path Down
(Propagating access link alarm)". The downstream PE shall translate
this into AIS in the forward direction and RDI in the reverse
direction.
5. Like-to-Like Scenarios
In the case of like-to-like PWs, MPLS ping can also be useful
in detecting and reporting problems. The following sections
will use ATMoMPLS as an example. Even though mechanisms for
transporting ATM OAM cells over the PW are well defined, as
described in the introduction, the support of such function is
optional. If OAM transport is supported and enabled, MPLS data-
plane failures may not be detected in time unless CC or
loopback OAM cells are used. Thus, MPLS ping can be very
useful, especially if the PE routers do not support transport
of OAM.
5.1. Mapping of MPLS Data Plane Failures
MPLS LSP Ping and VCCV failure can be used to generate the
appropriate alarms at the edges as shown below. In this case,
it is assumed that either the PEs do not support OAM transport
or that they do, but CC/LB is not enabled. Otherwise, if the
PEs support OAM transport and CC is enabled, it is likely that
MPLS data-plane failure will be detected within 3.5+ - 0.5 sec
(CC timeout).
5.2. Mapping of Continuity Check
If PEs do not support transport of OAM cells, and segment CC
is supported/enabled but terminated at the PEs, then MPLS data-
plane failure can be detected by BFD control messages.Failure of the
BFD continuity check should be used to trigger AIS States at the two
PEs. i.e. generate AIS on the corresponding PW PVCs at a rate of 1
AIS per sec per VC.
5.3. Mapping of Loopback
As described in section 4.8 some potential improvements can
be achieved if ATM segment LB tests happen to be successful,
but the PEs use the ATM LB test to trigger automatic MPLS
ping. In this case, if we assume that the ATM network is
functional but there is a problem in the MPLS data-plane, then
invoking ATM segment LB test will result in successful LB, but
the PE at the ATM side will generate AIS if the MPLS ping
fails.
6. L2TPv3 Message Mapping
[TBD]
7. Ethernet Interworking Mapping
[TBD]
8. VPLS
[TBD]
9. Security Considerations
The mapping messages described in this document do not change
the security functions inherent in the actual messages.
10. Acknowledgments
Hari Rakotoranto, Eric Rosen, Mark Townsely, Michel
Khouderchah, Bertrand Duvivier, Vanson Lim and Chris
Metz Cisco Systems.
11. References
[VCCV] Nadeau, T., et al. "Pseudo Wire Virtual
Circuit Connection Verification (VCCV)", Internet
Draft <draft-ietf-pwe3-vccv-01.txt>, October
2003.
[BFD] Katz, D., Ward, D., Bidirectional Forwarding
Indication, draft-katz-ward-bfd-00.txt, December
2003, work in progress.
[PWREQ] Xiao, X., McPherson, D., Pate, P., Gill, V.,
Kompella, K., Nadeau, T., White, C., "Requirements
for Pseudo Wire Emulation
Edge-to-Edge (PWE3)", <draft-ietf-pwe3-requirements-
02.txt>, November 2001.
[PWE3FW] Prayson Pate, et al., Internet draft, Framework for
Pseudo Wire Emulation Edge-to-Edge (PWE3), draft-
ietf-pwe3-framework-01.txt, work in progress.
[PWEARCH] Bryant, S., Pate, P., Johnson, T., Kompella, K.,
Malis, A., McPherson, D., Nadeau, T., So, T.,
Townsley, W., Systems, White., C., Wood, L.,
Xiao, X., Internet draft, Framework for
Pseudo Wire Emulation Edge-to-Edge (PWE3), draft-
ietf-pwe3-framework-01.txt, work in progress.
[L2SIG] Rosen, E., LDP-based Signaling for L2VPNs,
Internet Draft <draft-rosen-ppvpn-l2-signaling-02.txt>,
September 2002.
[LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,
Swallow, G., Wadhwa, S., Bonica, R., " Detecting
Data Plane Liveliness in MPLS", Internet Draft
<draft-ietf-mpls-lsp-ping-01.txt>, April
2003.
[GTTP] Bonica, R., Kompella, K., Meyer, D., "Generic
Tunnel Tracing
Protocol (GTTP) Specification", Internet Draft
<draft-bonica-tunproto-01.txt>, April, 2003
[FRF 8.1] Frame Relay Forum, Frame Relay / ATM PVC Service
Interworking Implementation Agreement,February 2000
[ITU-T] "Draft Recommendation Y.17fw" (MPLS Management
Framework), July 2002.
[ITU-T] "Frame Relay Bearer Service Interworking," I.555,
September 2997.
[ITU-T], "Frame Relay Operations Principles and Functions, "
I.620, October, 1996.
[ITU-T] Q.933, ISDN Digital Subscriber Signalling System
No. 1 (DSS 1) - Signalling specification for
frame mode basic call control,
November 1995.
[ICMP] Postel, J. "Internet Control Message Protocol, "
RFC 792
[PWEATM] Martini, L., et al., "Encapsulation Methods for
Transport of ATM Cells/Frame Over IP and MPLS Networks,"
Internet Draft <draft-
ietf-pwe3-atm-encap-00.txt>, October 2002
[MPLSOAMREQS] Nadeau, T., et al, OAM Requirements for MPLS
Networks, Internet Draft <draft-ietf-mpls-oam-
requirements-00.txt>, February 2003.
[PWE3CONTROL] L.Martini et al., Transport of Layer 2 Frames
over MPLS, Internet Draft, <draft-ietf-pwe3-control-
protocol-01.txt>, May 2003
[PPVPNFW] Callon, R., Suzuki, M., Gleeson, B., Malis, A.,
Muthukrishnan, K., Rosen, E., Sargor, C., and J.
Yu, "A Framework for Provider Provisioned Virtual
Private Networks", Internet Draft
<draft-ietf-ppvpn-framework-01.txt>, July 2001.
[SAJASSI] A.Sajassi et al., "L2VPN Interworking," Internet
Draft <draft-sajassi-l2vpn-interworking-00.txt>,
November 2002.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
12. Intellectual Property Rights Notices
The IETF takes no position regarding the validity or scope
of any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license under
such rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found in
BCP-11. Copies of claims of rights made available for publication
and any assurances of licenses to be made available, or the result
of an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementers or users of
this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be required to
practice this standard. Please address the information to the IETF
Executive Director.
13. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
12. Contributors
Authors' Addresses
Thomas D. Nadeau Monique Morrow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive Glatt-com
Chelmsford, MA 01824 CH-8301 Glattzentrum
Email: tnadeau@cisco.com Switzerland
Email: mmorrow@cisco.com
Yuichi Ikejiri Kenji Kumaki
NTT Communications Corporation KDDI Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku KDDI Bldg. 2-3-2
Tokyo 100-8019 Nishishinjuku, Shinjuku-ku
JAPAN Tokyo 163-8003
Email: y.ikejiri@ntt.com JAPAN
E-mail : ke-kumaki@kddi.com
Satoru Matsushima Peter B. Busschbach
Japan Telecom Lucent Technologies
JAPAN 67 Whippany Road
Email: satoru@ft.solteria.net Whippany, NJ, 07981
Email: busschbach@lucent.com