< draft-ietf-pwe3-requirements-07.txt   draft-ietf-pwe3-requirements-08.txt >
Internet Draft XiPeng Xiao Internet Draft XiPeng Xiao
Document: draft-ietf-pwe3-requirements-07.txt Riverstone Networks Document: draft-ietf-pwe3-requirements-08.txt Riverstone Networks
Expires: Apr. 2004 Expires: Jun. 2004
Danny McPherson Danny McPherson
Arbor Networks Arbor Networks
Prayson Pate Prayson Pate
Overture Networks Overture Networks
Editors Editors
Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
draft-ietf-pwe3-requirements-07.txt draft-ietf-pwe3-requirements-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 3, line 9 skipping to change at page 3, line 9
Craig White Level 3 Communications, LLC. Craig White Level 3 Communications, LLC.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Table of Contents Table of Contents
1 Terminology .................................................. 4 1 Terminology .................................................. 4
2 Introduction ................................................. 4 2 Introduction ................................................. 4
2.1 What Are Pseudo Wires? ..................................... 5 2.1 What Are Pseudo Wires? ..................................... 5
2.2 Background and Motivation .................................. 5 2.2 Current Network Architecture .............................. 5
2.3 Current Network Architecture ............................... 5 2.3 PWE3 as a Path to Convergence .............................. 6
2.4 PWE3 as a Path to Convergence .............................. 6 2.4 Suitable Applications for PWE3 ............................. 6
2.5 Suitable Applications for PWE3 ............................. 6 2.5 Summary .................................................... 7
2.6 Summary .................................................... 7
3 Reference Model of PWE3 ...................................... 7 3 Reference Model of PWE3 ...................................... 7
4 Packet Processing ............................................ 8 4 Packet Processing ............................................ 8
4.1 Encapsulation .............................................. 8 4.1 Encapsulation .............................................. 8
4.2 Frame Ordering ............................................. 9 4.2 Frame Ordering ............................................. 9
4.3 Frame Duplication .......................................... 9 4.3 Frame Duplication .......................................... 9
4.4 Fragmentation .............................................. 10 4.4 Fragmentation .............................................. 10
4.5 Consideration of Per-PSN Packet Overhead ................... 10 4.5 Consideration of Per-PSN Packet Overhead ................... 10
5 Maintenance of Emulated Services ............................. 10 5 Maintenance of Emulated Services ............................. 10
5.1 Setup and Teardown of Pseudo-Wires ......................... 10 5.1 Setup and Teardown of Pseudo-Wires ......................... 10
5.2 Handling Maintenance Message of the Native Services ........ 11 5.2 Handling Maintenance Message of the Native Services ........ 11
skipping to change at page 3, line 38 skipping to change at page 3, line 37
6.3 Configuration and Provisioning ............................. 13 6.3 Configuration and Provisioning ............................. 13
6.4 Performance Monitoring ..................................... 13 6.4 Performance Monitoring ..................................... 13
6.5 Fault Management and Notifications ......................... 14 6.5 Fault Management and Notifications ......................... 14
6.6 Pseudo-Wire Connection Verification and Traceroute ........ 14 6.6 Pseudo-Wire Connection Verification and Traceroute ........ 14
7 Faithfulness of Emulated Services ............................ 14 7 Faithfulness of Emulated Services ............................ 14
7.1 Characteristics of an Emulated Service ..................... 14 7.1 Characteristics of an Emulated Service ..................... 14
7.2 Service Quality of Emulated Services ....................... 15 7.2 Service Quality of Emulated Services ....................... 15
8 Non-Requirements ............................................. 15 8 Non-Requirements ............................................. 15
9 Quality of Service (QoS) Considerations ...................... 16 9 Quality of Service (QoS) Considerations ...................... 16
10 Inter-domain Issues ......................................... 16 10 Inter-domain Issues ......................................... 16
11 Security Considerations ..................................... 16 11 Security Considerations ..................................... 17
12 Acknowledgments ............................................. 17 12 Acknowledgments ............................................. 17
13 References .................................................. 17 13 References .................................................. 17
13.1 Normative References ...................................... 17
13.2 Non-normative References .................................. 17
14 Authors' Addresses .......................................... 18 14 Authors' Addresses .......................................... 18
15 Full Copyright Section ...................................... 19 15 Full Copyright Section ...................................... 20
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Some terms used throughout this document are listed below. Some terms used throughout this document are listed below.
Attachment Circuit (AC) Attachment Circuit (AC)
The physical or virtual circuit attaching a CE to The physical or virtual circuit attaching a CE to
skipping to change at page 5, line 21 skipping to change at page 5, line 21
managing their timing and order, and any other operations required to managing their timing and order, and any other operations required to
emulate the behavior and characteristics of the service as faithfully emulate the behavior and characteristics of the service as faithfully
as possible. as possible.
From the customer perspective, the PW is perceived as an unshared From the customer perspective, the PW is perceived as an unshared
link or circuit of the chosen service. However, there may be link or circuit of the chosen service. However, there may be
deficiencies that impede some applications from being carried on a deficiencies that impede some applications from being carried on a
PW. These limitations should be fully described in the appropriate PW. These limitations should be fully described in the appropriate
service-specific documents and Applicability Statements. service-specific documents and Applicability Statements.
2.2. Background and Motivation 2.2. Current Network Architecture
The following sections give some background on where networks are The following sections give some background on where networks are
today and why they are changing. It also talks about the motivation today and why they are changing. It also talks about the motivation
to provide converged networks while continuing to support existing to provide converged networks while continuing to support existing
services. Finally it discusses how PWs can be a solution for this services. Finally it discusses how PWs can be a solution for this
dilemma. dilemma.
2.3. Current Network Architecture 2.2.1. Multiple Networks
2.3.1. Multiple Networks
For any given service provider delivering multiple services, the For any given service provider delivering multiple services, the
current infrastructure usually consists of parallel or "overlay" current infrastructure usually consists of parallel or "overlay"
networks. Each of these networks implements a specific service, such networks. Each of these networks implements a specific service, such
as Frame Relay, Internet access, etc. This is expensive, both in as Frame Relay, Internet access, etc. This is expensive, both in
terms of capital expense and operational costs. Furthermore, the terms of capital expense and operational costs. Furthermore, the
presence of multiple networks complicates planning. Service providers presence of multiple networks complicates planning. Service providers
wind up asking themselves these questions: wind up asking themselves these questions:
- Which of my networks do I build out? - Which of my networks do I build out?
- How many fibers do I need for each network? - How many fibers do I need for each network?
- How do I efficiently manage multiple networks? - How do I efficiently manage multiple networks?
A converged network helps service providers answer these questions in A converged network helps service providers answer these questions in
a consistent and economical fashion. a consistent and economical fashion.
2.3.2. Transition to a Packet-Optimized Converged Network 2.2.2. Transition to a Packet-Optimized Converged Network
In order to maximize return on their assets and minimize their In order to maximize return on their assets and minimize their
operating costs, service providers often look to consolidate the operating costs, service providers often look to consolidate the
delivery of multiple service types onto a single networking delivery of multiple service types onto a single networking
technology. technology.
As packet traffic takes up a larger and larger portion of the As packet traffic takes up a larger and larger portion of the
available network bandwidth, it becomes increasingly useful to available network bandwidth, it becomes increasingly useful to
optimize public networks for the Internet Protocol. However, many optimize public networks for the Internet Protocol. However, many
service providers are confronting several obstacles in engineering service providers are confronting several obstacles in engineering
skipping to change at page 6, line 22 skipping to change at page 6, line 21
bit. For example, Frame Relay traffic currently generates higher bit. For example, Frame Relay traffic currently generates higher
revenue per bit than native IP services do. Private line TDM revenue per bit than native IP services do. Private line TDM
services still generate even more revenue per bit than does Frame services still generate even more revenue per bit than does Frame
Relay. In addition, there is a tremendous amount of legacy equipment Relay. In addition, there is a tremendous amount of legacy equipment
deployed within public networks that does not communicate using the deployed within public networks that does not communicate using the
Internet Protocol. Service providers continue to utilize non-IP Internet Protocol. Service providers continue to utilize non-IP
equipment to deploy a variety of services, and see a need to equipment to deploy a variety of services, and see a need to
interconnect this legacy equipment over their IP-optimized core interconnect this legacy equipment over their IP-optimized core
networks. networks.
2.4. PWE3 as a Path to Convergence 2.3. PWE3 as a Path to Convergence
How do service providers realize the capital and operational benefits How do service providers realize the capital and operational benefits
of a new packet-based infrastructure, while leveraging the existing of a new packet-based infrastructure, while leveraging the existing
equipment and also protecting the large revenue stream associated equipment and also protecting the large revenue stream associated
with this equipment? How do they move from mature Frame Relay or ATM with this equipment? How do they move from mature Frame Relay or ATM
networks, while still being able to provide these lucrative services? networks, while still being able to provide these lucrative services?
One possibility is the emulation of circuits or services via PWs. One possibility is the emulation of circuits or services via PWs.
Circuit emulation over ATM and interworking of Frame Relay and ATM Circuit emulation over ATM and interworking of Frame Relay and ATM
have already been standardized. Emulation allows existing services to have already been standardized. Emulation allows existing services to
be carried across the new infrastructure, and thus enables the be carried across the new infrastructure, and thus enables the
interworking of disparate networks. interworking of disparate networks.
Implemented correctly, PWE3 can provide a means for supporting Implemented correctly, PWE3 can provide a means for supporting
today's services over a new network. today's services over a new network.
2.5. Suitable Applications for PWE3 2.4. Suitable Applications for PWE3
What makes an application suitable (or not) for PWE3 emulation? When What makes an application suitable (or not) for PWE3 emulation? When
considering PWs as a means of providing an application, the following considering PWs as a means of providing an application, the following
questions must be considered: questions must be considered:
- Is the application sufficiently deployed to warrant emulation? - Is the application sufficiently deployed to warrant emulation?
- Is there interest on the part of service providers in providing an - Is there interest on the part of service providers in providing an
emulation for the given application? emulation for the given application?
- Is there interest on the part of equipment manufacturers in - Is there interest on the part of equipment manufacturers in
providing products for the emulation of a given application? providing products for the emulation of a given application?
- Are the complexities and limitations of providing an emulation - Are the complexities and limitations of providing an emulation
worth the savings in capital and operational expenses? worth the savings in capital and operational expenses?
If the answer to all four questions is "yes", then the application is If the answer to all four questions is "yes", then the application is
likely to be a good candidate for PWE3. Otherwise, there may not be likely to be a good candidate for PWE3. Otherwise, there may not be
sufficient overlap between the customers, service providers, sufficient overlap between the customers, service providers,
equipment manufacturers and technology to warrant providing such an equipment manufacturers and technology to warrant providing such an
emulation. emulation.
2.6. Summary 2.5. Summary
To maximize the return on their assets and minimize their operational To maximize the return on their assets and minimize their operational
costs, many service providers are looking to consolidate the delivery costs, many service providers are looking to consolidate the delivery
of multiple service offerings and traffic types onto a single IP- of multiple service offerings and traffic types onto a single IP-
optimized network. optimized network.
In order to create this next-generation converged network, standard In order to create this next-generation converged network, standard
methods must be developed to emulate existing telecommunications methods must be developed to emulate existing telecommunications
formats such as Ethernet, Frame Relay, and ATM over IP-optimized core formats such as Ethernet, Frame Relay, and ATM over IP-optimized core
networks. This document describes requirements for accomplishing networks. This document describes requirements for accomplishing
skipping to change at page 9, line 30 skipping to change at page 9, line 25
then be re-calculated and inserted at the egress PE. For protocols then be re-calculated and inserted at the egress PE. For protocols
such as ATM and FR, the checksum covers link-local information such such as ATM and FR, the checksum covers link-local information such
as the circuit identifiers (e.g. FR DLCI or ATM VPI/VCI). Therefore, as the circuit identifiers (e.g. FR DLCI or ATM VPI/VCI). Therefore,
such checksum MUST be removed at the ingress PE and recalculated at such checksum MUST be removed at the ingress PE and recalculated at
the egress PE. the egress PE.
4.1.5. Conveyance of Payload Type Information 4.1.5. Conveyance of Payload Type Information
Under some circumstances, it is desirable to be able to distinguish Under some circumstances, it is desirable to be able to distinguish
PW traffic from other types of traffic such as IPv4 or IPv6 or OAM. PW traffic from other types of traffic such as IPv4 or IPv6 or OAM.
For example, if ECMP is employed in a PSN, this additional For example, if Equal Cost Multi-Path (ECMP) is employed in a PSN,
distinguishability can be used to reduce the chance that PW packets this additional distinguishability can be used to reduce the chance
get misordered by the load balancing mechanism. Some mechanism SHOULD that PW packets get misordered by the load balancing mechanism. Some
provide this distinguishability if needed. Such mechanism MAY be mechanism SHOULD provide this distinguishability if needed. Such
defined in the PWE3 WG or other WGs. mechanism MAY be defined in the PWE3 WG or other WGs.
4.2. Frame Ordering 4.2. Frame Ordering
When packets carrying the PW PDUs traverse a PW, they may arrive at When packets carrying the PW PDUs traverse a PW, they may arrive at
the egress out of order. For some services, the frames (either the egress out of order. For some services, the frames (either
control frames only or both control and data frames) must be control frames only or both control and data frames) must be
delivered in order. For such services, some mechanism MUST be delivered in order. For such services, some mechanism MUST be
provided for ensuring in-order delivery. Providing a sequence number provided for ensuring in-order delivery. Providing a sequence number
in the PW header for each packet is one possible approach to detect in the PW header for each packet is one possible approach to detect
out-of-order frames. Mechanisms for re-ordering frames may be out-of-order frames. Mechanisms for re-ordering frames may be
skipping to change at page 10, line 40 skipping to change at page 10, line 39
larger penalty incurred by packet loss. larger penalty incurred by packet loss.
5. Maintenance of Emulated Services 5. Maintenance of Emulated Services
This section describes maintenance requirements for PWE3. This section describes maintenance requirements for PWE3.
5.1. Setup and Teardown of Pseudo-Wires 5.1. Setup and Teardown of Pseudo-Wires
A PW must be set up before an emulated circuit can be established, A PW must be set up before an emulated circuit can be established,
and must be torn down when an emulated circuit is no longer needed. and must be torn down when an emulated circuit is no longer needed.
Setup and teardown of a PW can be triggered by a CLI command from the Setup and teardown of a PW can be triggered by a command from the
management plane of a PE, or by Setup/Teardown of an AC (e.g., an ATM management plane of a PE, or by Setup/Teardown of an AC (e.g., an ATM
SVC), or by an auto-discovery mechanism. SVC), or by an auto-discovery mechanism.
Every PWE3 approach MUST define some setup mechanism for establishing Every PWE3 approach MUST define some setup mechanism for establishing
the PWs. During the setup process, the PEs need to exchange some the PWs. During the setup process, the PEs need to exchange some
information (e.g. to learn each other's capability). The setup information (e.g. to learn each other's capability). The setup
mechanism MUST enable the PEs to exchange all necessary information. mechanism MUST enable the PEs to exchange all necessary information.
For example, both endpoints must agree on methods for encapsulating For example, both endpoints must agree on methods for encapsulating
PDUs and handling frame ordering. Which signaling protocol to use and PDUs and handling frame ordering. Which signaling protocol to use and
what information to exchange are service specific. Every PWE3 what information to exchange are service specific. Every PWE3
skipping to change at page 13, line 32 skipping to change at page 13, line 29
6.2. General MIB Requirements 6.2. General MIB Requirements
New MIBs MUST augment or extend where appropriate, existing tables as New MIBs MUST augment or extend where appropriate, existing tables as
defined in other existing service-specific MIBs for existing services defined in other existing service-specific MIBs for existing services
such as MPLS or L2TP. For example, the ifTable as defined in the such as MPLS or L2TP. For example, the ifTable as defined in the
Interface MIB [IFMIB] MUST be augmented to provide counts of out-of- Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-
order packets. A second example is the extension of the MPLS-TE-MIB order packets. A second example is the extension of the MPLS-TE-MIB
[TEMIB] when emulating circuit services over MPLS. Rather than [TEMIB] when emulating circuit services over MPLS. Rather than
redefining the tunnelTable so that PWE can utilize MPLS tunnels, for redefining the tunnelTable so that PWE can utilize MPLS tunnels, for
example, entries in this table MUST instead be extended to add example, entries in this table MUST instead be extended to add
additional PWE-specific objects. Doing so facilitates a natural additional PWE-specific objects. A final example might be to extend
extension of those objects defined in the existing MIBs in terms of the IP Tunnel MIB [IPTUNMIB] in such a way as to provide PWE3-
management, as well as leveraging existing agent implementations. specific semantics when tunnels other than MPLS are used as PSN
transport. Doing so facilitates a natural extension of those objects
defined in the existing MIBs in terms of management, as well as
leveraging existing agent implementations.
An AC MUST appear as an interface in the ifTable. An AC MUST appear as an interface in the ifTable.
6.3. Configuration and Provisioning 6.3. Configuration and Provisioning
MIB Tables MUST be designed to facilitate configuration and MIB Tables MUST be designed to facilitate configuration and
provisioning of the AC. provisioning of the AC.
The MIB(s) MUST facilitate intra-PSN configuration and monitoring of The MIB(s) MUST facilitate intra-PSN configuration and monitoring of
ACs. ACs.
skipping to change at page 16, line 28 skipping to change at page 16, line 28
In order to take advantage of QoS mechanisms defined in other working In order to take advantage of QoS mechanisms defined in other working
groups, e.g. the traffic management schemes defined in DiffServ WG, groups, e.g. the traffic management schemes defined in DiffServ WG,
it is desirable that some mechanisms exists for differentiating the it is desirable that some mechanisms exists for differentiating the
packets resulted from PDU encapsulation. These mechanisms do not have packets resulted from PDU encapsulation. These mechanisms do not have
to be defined in the PWE3 approaches themselves. For example, if the to be defined in the PWE3 approaches themselves. For example, if the
resulted packets are MPLS or IP packets, their EXP or DSCP field can resulted packets are MPLS or IP packets, their EXP or DSCP field can
be used for marking and differentiating. A PWE3 approach MAY provide be used for marking and differentiating. A PWE3 approach MAY provide
guidelines for marking and differentiating. guidelines for marking and differentiating.
The applicability of PWE3 to a particular service depends on the
sensitivity of that service (or the CE implementation) to
delay/jitter etc and the ability of the application layer to mask
them. PWE3 may not be applicable to services that have severe
constraints in this respect.
10. Inter-domain Issues 10. Inter-domain Issues
PWE is a matter between the PW end-points and is transparent to the PWE is a matter between the PW end-points and is transparent to the
network devices between the PW end-points. Therefore, inter-domain network devices between the PW end-points. Therefore, inter-domain
PWE is fundamentally similar to intra-domain PWE. As long as PW PWE is fundamentally similar to intra-domain PWE. As long as PW
end-points use the same PWE approach, they can communicate end-points use the same PWE approach, they can communicate
effectively, regardless of whether they are in the same domain. effectively, regardless of whether they are in the same domain.
Security may become more important in the inter-domain case and some Security may become more important in the inter-domain case and some
security measure such as end-point authentication MAY be applied. security measure such as end-point authentication MAY be applied.
QoS may become more difficult to deliver too, as one service provider
has no control over another service provider's provisioning and
traffic management policy. To solve the inter-domain QoS problem,
service providers have to cooperate. Once they agree at a contractual
level to provider high quality of service to certain traffic (e.g.
PWE traffic), the mechanisms defined in other working groups, e.g.
Diffserv WG, can be used.
Inter-domain PSN tunnels are generally more difficult to set up, tear Inter-domain PSN tunnels are generally more difficult to set up, tear
down and maintain than intra-domain ones. But that is an issue for down and maintain than intra-domain ones. But that is an issue for
PSN tunneling protocols such as MPLS and L2TPv3 and is outside the PSN tunneling protocols such as MPLS and L2TPv3 and is outside the
scope of PWE3. scope of PWE3.
11. Security Considerations 11. Security Considerations
The PW end-point, PW demultiplexing mechanism, and the payloads of The PW end-point, PW demultiplexing mechanism, and the payloads of
the native service can all be vulnerable to attack. PWE3 should the native service can all be vulnerable to attack. PWE3 should
leverage security mechanisms provided by the PW Demultiplexer or PSN leverage security mechanisms provided by the PW Demultiplexer or PSN
Layers. Such mechanisms SHOULD protect PW end-point and PW Layers. Such mechanisms SHOULD protect PW end-point and PW
Demultiplexer mechanism from denial-of-service (DoS) attacks and Demultiplexer mechanism from denial-of-service (DoS) attacks and
spoofing of the native data units. Controlling PSN access to the PW spoofing of the native data units. Preventing unauthorized access to
end-point is generally effective against DoS attacks and spoofing, PW end-points and other network devices is generally effective
and can be part of protection mechanism. Protection mechanisms against DoS attacks and spoofing, and can be part of protection
SHOULD also address the spoofing of tunneled PW data. The validation mechanism. Protection mechanisms SHOULD also address the spoofing of
of traffic addressed to the PW Demultiplexer end-point is paramount tunneled PW data. The validation of traffic addressed to the PW
in ensuring integrity of PW encapsulation. Security protocols such Demultiplexer end-point is paramount in ensuring integrity of PW
as IPSec [RFC2401] can be used. encapsulation. Security protocols such as IPSec [RFC2401] can be
used.
12. Acknowledgments 12. Acknowledgments
The authors would like to acknowledge input from M. Aissaoui, M. The authors would like to acknowledge input from M. Aissaoui, M.
Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A. Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A.
Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein and S. Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein and S.
Vainshtein. Vainshtein.
13. References 13. References
13.1. Normative References
[IFMIB] K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB
using SMIv2", RFC 2863, Jun. 2000.
[SMIV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Structure of Management Information for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 2578, Apr.
1999.
13.2. Non-normative References
[G805] "Generic Functional Architecture of Transport Networks", [G805] "Generic Functional Architecture of Transport Networks",
ITU-T Recommendation G.805, 2000. ITU-T Recommendation G.805, 2000.
[IFMIB] K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB [IPTUNMIB] D. Thaler, "IP Tunnel MIB", RFC2667, Aug. 1999.
using SMIv2", RFC 2233, Nov. 1997.
[L2TPv3] J. Lau, M. Townsley, and I. Goyret, et. al., "Layer Two [L2TPv3] J. Lau, M. Townsley, and I. Goyret, et. al., "Layer Two
Tunneling Protocol (Version 3)", <draft-ietf-l2tpext-l2tp- Tunneling Protocol (Version 3)", <draft-ietf-l2tpext-l2tp-
base-10.txt>, work in progress, Aug. 2003. base-10.txt>, work in progress, Aug. 2003.
[MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based [MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based
ATM Networks", RFC2022, November 1996 ATM Networks", RFC2022, November 1996
[MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol [MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
Label Switching Architecture", RFC3031, January 2001 Label Switching Architecture", RFC3031, January 2001
[PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture", [PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture",
<draft-ietf-pwe3-arch-06.txt>, work in progress, Oct. 2003. <draft-ietf-pwe3-arch-06.txt>, work in progress, Oct. 2003.
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, Nov. 1998. Internet Protocol", RFC 2401, Nov. 1998.
[SMIV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Structure of Management Information for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1902, Jan.
1996.
[TEMIB] C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic [TEMIB] C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic
Engineering Management Information Base", <draft-ietf-mpls- Engineering Management Information Base", <draft-ietf-mpls-
te-mib-12.txt>, work in progress, Aug. 2003. te-mib-12.txt>, work in progress, Aug. 2003.
[UNI3.0] ATM Forum, "ATM User-Network Interface Specification Version [UNI3.0] ATM Forum, "ATM User-Network Interface Specification Version
3.0", Sept. 1993. 3.0", Sept. 1993.
14. Authors' Addresses 14. Authors' Addresses
XiPeng Xiao XiPeng Xiao
 End of changes. 23 change blocks. 
42 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/