< draft-ietf-pwe3-packet-pw-02.txt   draft-ietf-pwe3-packet-pw-03.txt >
Network Working Group S. Bryant, Ed. Network Working Group S. Bryant, Ed.
Internet-Draft L. Martini Internet-Draft L. Martini
Intended status: BCP G. Swallow Intended status: Standards Track G. Swallow
Expires: June 22, 2012 Cisco Systems Expires: July 31, 2012 Cisco Systems
A. Malis A. Malis
Verizon Communications Verizon Communications
December 20, 2011 January 28, 2012
Packet Pseudowire Encapsulation over an MPLS PSN Packet Pseudowire Encapsulation over an MPLS PSN
draft-ietf-pwe3-packet-pw-02.txt draft-ietf-pwe3-packet-pw-03.txt
Abstract Abstract
This document describes a pseudowire mechanism that is used to This document describes a pseudowire mechanism that is used to
transport a packet service over an MPLS PSN is the case where the transport a packet service over an MPLS PSN is the case where the
client LSR and the server PE are co-resident in the same equipment. client Label Switching Router (LSR) and the server Provider Edge
This pseudowire mechanism may be used to carry all of the required equipments are co-resident in the same equipment. This pseudowire
layer 2 and layer 3 protocols between the pair of client LSRs. mechanism may be used to carry all of the required layer 2 and layer
3 protocols between the pair of client LSRs.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 43 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 22, 2012. This Internet-Draft will expire on July 31, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network Reference Model . . . . . . . . . . . . . . . . . . . 3 2. Network Reference Model . . . . . . . . . . . . . . . . . . . 4
3. Client Network Layer Model . . . . . . . . . . . . . . . . . . 4 3. Client Network Layer Model . . . . . . . . . . . . . . . . . . 4
4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5 4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5
5. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 6 5. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 6
6. Ethernet Functional Restrictions . . . . . . . . . . . . . . . 8 6. Ethernet Functional Restrictions . . . . . . . . . . . . . . . 8
7. Congestion Considerations . . . . . . . . . . . . . . . . . . 8 7. Congestion Considerations . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Encapsulation Approaches Considered . . . . . . . . . 10 Appendix A. Encapsulation Approaches Considered . . . . . . . . . 10
A.1. A Protocol Identifier in the Control Word . . . . . . . . 10 A.1. A Protocol Identifier in the Control Word . . . . . . . . 11
A.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 11 A.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 11
A.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . 12 A.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . 12
A.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . 12 A.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . 13
A.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 13 A.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
There is a need to provide a method of carrying a packet service over There is a need to provide a method of carrying a packet service over
an MPLS PSN in a way that provides isolation between the two an MPLS PSN in a way that provides isolation between the two
networks. The server MPLS network may be an MPLS network or a networks. The server MPLS network may be an MPLS network or a
network conforming to the MPLS-TP [RFC5317]. The client may also be network conforming to the MPLS Transport Profile (MPLS-TP) [RFC5317].
either a MPLS network of a network conforming to the MPLS-TP. The client may also be either an MPLS network or a network conforming
Considerations regarding the use of an MPLS network as a server for to the MPLS-TP. Considerations regarding the use of an MPLS network
an MPLS-TP network are outside the scope of this document. as a server for an MPLS-TP network are outside the scope of this
document.
Where the client equipment is connected to the server equipment via Where the client equipment is connected to the server equipment via a
physical interface, the same data-link type MUST be used to attach physical interface, the same data-link type MUST be used to attach
the clients to the Provider Edge equipments (PE)s, and a pseudowire the clients to the Provider Edge equipments (PE)s, and a pseudowire
(PW) of the same type as the data-link MUST be used [RFC3985]. The (PW) of the same type as the data-link MUST be used [RFC3985]. The
reason that inter-working between different physical and data-link reason that inter-working between different physical and data-link
attachment types is specifically disallowed in the pseudowire attachment types is specifically disallowed in the pseudowire
architecture is because this is a complex task and not a simple bit- architecture is because this is a complex task and not a simple bit-
mapping exercise. The inter-working is not limited to the physical mapping exercise. The inter-working is not limited to the physical
and data-link interfaces and the state-machines. It also requires a and data-link interfaces and the state-machines. It also requires a
compatible approach to the formation of the adjacencies between compatible approach to the formation of the adjacencies between
attached client network equipment. As an example the reader should attached client network equipment. As an example the reader should
consider the differences between router adjacency formation on a consider the differences between router adjacency formation on a
point to point link compared to a multi-point to multi-point point-to-point link compared to a multipoint-to-multipoint interface
interface (e.g. Ethernet). (e.g. Ethernet).
A further consideration is that two adjacent MPLS LSRs do not simply A further consideration is that two adjacent MPLS Label Switching
exchange MPLS packets. They exchange IP packets for adjacency Routers (LSRs) do not simply exchange MPLS packets. They exchange IP
formation, control, routing, label exchange, management and packets for adjacency formation, control, routing, label exchange,
monitoring purposes. In addition they may exchange data-link packets management and monitoring purposes. In addition they may exchange
as part of routing (e.g. IS-IS hellos and IS-IS LSPs) and for OAM data-link packets as part of routing (e.g. IS-IS Hellos and IS-IS
purposes such as Link Layer Discovery protocol [IEEE standard Link State Packets) and for Operations, Administration, and
802.1AB-2009]. Thus the two clients require an attachment mechanism Maintenance (OAM) purposes such as Link Layer Discovery protocol
that can be used to multiplex a number of protocols. In addition it [IEEE standard 802.1AB-2009]. Thus the two clients require an
is essential to the correct operation of the network layer that all attachment mechanism that can be used to multiplex a number of
of these protocols fate share. protocols. In addition it is essential to the correct operation of
the network layer that all of these protocols fate share.
Where the client LSR and server PE is co-located in the same Where the client LSR and server PE is co-located in the same
equipment, the data-link layer can be simplified to a point to point equipment, the data-link layer can be simplified to a point-to-point
Ethernet used to multiplex the various data-link types onto a Ethernet used to multiplex the various data-link types onto a
pseudowire. This is the method that described in this document. pseudowire. This is the method that described in this document.
Non-normative Appendix Appendix A provides information on alternative
approaches to providing a packet PW that were considered by PWE3
Working Group and the reasons for using the method defined in this
specification.
2. Network Reference Model 2. Network Reference Model
The network reference model for the packet pseudowire operating in an The network reference model for the packet pseudowire operating in an
MPLS network is shown in Figure 1. This is an extension of Figure 3 MPLS network is shown in Figure 1. This is an extension of Figure 3
"Pre-processing within the PWE3 Network Reference Model" from "Pre-processing within the PWE3 Network Reference Model" from
[RFC3985]. [RFC3985].
PW PW PW PW
End Service End Service End Service End Service
| | | |
skipping to change at page 4, line 28 skipping to change at page 4, line 35
) | | |================| | | ( ) | | |================| | | (
------- +-----+-----+ +-----+-----+ -------- ------- +-----+-----+ +-----+-----+ --------
^ ^ ^ ^
| | | |
| | | |
|<---- Emulated Service----->| |<---- Emulated Service----->|
| | | |
Virtual physical Virtual physical Virtual physical Virtual physical
termination termination termination termination
Figure 1 Figure 1: Packet PW Network Reference Model
In this model LSRs, LSR1 and LSR2, are part of the client MPLS packet In this model LSRs, LSR1 and LSR2, are part of the client MPLS PSN.
switched network (PSN). The PEs, PE1 and PE2 are part of the server The PEs, PE1 and PE2 are part of the server PSN, that is to be used
PSN, that is to be used to provide connectivity between the client to provide connectivity between the client LSRs. The attachment
LSRs. The attachment circuit that is used to connect the MPLS LSRs circuit that is used to connect the MPLS LSRs to the PEs is a virtual
to the PEs is a virtual interface within the equipment. A packet interface within the equipment. A packet pseudowire is used to
pseudowire is used to provide connectivity between these virtual provide connectivity between these virtual interfaces. This packet
interfaces. This packet pseudowire is used to transport all of the pseudowire is used to transport all of the required layer 2 and layer
required layer 2 and layer 3 between protocols between LSR1 and LSR2. 3 between protocols between LSR1 and LSR2.
3. Client Network Layer Model 3. Client Network Layer Model
The packet PW appears as a single point to point link to the client The packet PW appears as a single point-to-point link to the client
layer. Network Layer adjacency formation and maintenance between the layer. Network Layer adjacency formation and maintenance between the
client equipments will the follow normal practice needed to support client equipments will the follow normal practice needed to support
the required relationship in the client layer. The assignment of the required relationship in the client layer. The assignment of
metrics for this point to point link is a matter for the client metrics for this point-to-point link is a matter for the client
layer. In a hop by hop routing network the metrics would normally be layer. In a hop by hop routing network the metrics would normally be
assigned by appropriate configuration of the embedded client network assigned by appropriate configuration of the embedded client network
layer equipment (e.g. the embedded client LSR). Where the client was layer equipment (e.g. the embedded client LSR). Where the client was
using the packet PW as part of a traffic engineered path, it is up to using the packet PW as part of a traffic engineered path, it is up to
the operator of the client network to ensure that the server layer the operator of the client network to ensure that the server layer
operator provides the necessary service level agreement. operator provides the necessary service level agreement.
4. Forwarding Model 4. Forwarding Model
The packet PW forwarding model is illustrated in Figure 2. The The packet PW forwarding model is illustrated in Figure 2. The
skipping to change at page 5, line 36 skipping to change at page 5, line 44
+------------------------------------------------+ +------------------------------------------------+
Figure 2: Packet PW Forwarding Model Figure 2: Packet PW Forwarding Model
A packet PW PE comprises three components, the client LSR, PW A packet PW PE comprises three components, the client LSR, PW
processor and a server LSR. Note that [RFC3985] does not formally processor and a server LSR. Note that [RFC3985] does not formally
indicate the presence of the server LSR because it does not concern indicate the presence of the server LSR because it does not concern
itself with the server layer. However it is useful in this document itself with the server layer. However it is useful in this document
to recognise that the server LSR exists. to recognise that the server LSR exists.
It may be useful to first recall the operation of a layer two PW such It may be useful to first recall the operation of a layer 2 PW such
as an Ethernet PW [RFC4448] within this model. The client LSR is not as an Ethernet PW [RFC4448] within this model. The client LSR is not
present and packets arrive directly on the attachment circuit (AC) present and packets arrive directly on the attachment circuit (AC)
which is part of the client network. The PW function undertakes any which is part of the client network. The PW function undertakes any
header processing, if configured to do so, it then optionally pushes header processing, if configured to do so, it then optionally pushes
the PW control word (CW), and finally pushes the PW label. The PW the PW control word (CW), and finally pushes the PW label. The PW
function then passes the packet to the LSR function which pushes the function then passes the packet to the LSR function which pushes the
label needed to reach the egress PE and forwards the packet to the label needed to reach the egress PE and forwards the packet to the
next hop in the server network. At the egress PE, the packet next hop in the server network. At the egress PE, the packet
typically arrives with the PW label at top of stack, the packet is typically arrives with the PW label at top of stack, the packet is
thus directed to the correct PW instance. The PW instance performs thus directed to the correct PW instance. The PW instance performs
skipping to change at page 6, line 28 skipping to change at page 6, line 35
by the server LSR which uses the PW label to pass the packet to the by the server LSR which uses the PW label to pass the packet to the
correct PW instance. This PW instance processed the packet as correct PW instance. This PW instance processed the packet as
described in RFC4448. The resultant Ethernet encapsulated client described in RFC4448. The resultant Ethernet encapsulated client
packet is then passed to the egress client LSR which then processes packet is then passed to the egress client LSR which then processes
the packet in the normal manner. the packet in the normal manner.
Note that although the description above is written in terms of the Note that although the description above is written in terms of the
behaviour of an MPLS LSR, the processing model would be similar for behaviour of an MPLS LSR, the processing model would be similar for
an IP packet, or indeed any other protocol type. an IP packet, or indeed any other protocol type.
Note that the semantics of the PW between the client LSRs is a point Note that the semantics of the PW between the client LSRs is a point-
to point link. to-point link.
5. Packet PW Encapsulation 5. Packet PW Encapsulation
The client network work layer packet encapsulation into a packet PW The client network work layer packet encapsulation into a packet PW
is shown in Figure 3. is shown in Figure 3.
+-------------------------------+ +-------------------------------+
| Client | | Client |
| Network Layer | | Network Layer |
| packet | n octets | packet | n octets
skipping to change at page 7, line 24 skipping to change at page 7, line 24
| +---------------+ | +---------------+
| | | |
+---------------+---------------+ +---------------+---------------+
| Optional Control Word | 4 octets | Optional Control Word | 4 octets
+-------------------------------+ +-------------------------------+
| PW label | 4 octets | PW label | 4 octets
+-------------------------------+ +-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)
+-------------------------------+ +-------------------------------+
Figure 3 Figure 3: Packet PW Encapsulation
This conforms to the PW protocols stack as defined in [RFC4448]. The This conforms to the PW protocols stack as defined in [RFC4448]. The
protocol stack is unremarkable except to note that the stack does not protocol stack is unremarkable except to note that the stack does not
retain 32 bit alignment between the virtual Ethernet header and the retain 32 bit alignment between the virtual Ethernet header and the
PW optional control word (or the PW label when the optional PW optional control word (or the PW label when the optional
components are not present in the PW header). This loss of 32 bit of components are not present in the PW header). This loss of 32 bit of
alignment is necessary to preserve backwards compatibility with the alignment is necessary to preserve backwards compatibility with the
Ethernet PW design [RFC4448] Ethernet PW design [RFC4448]
Ethernet Raw Mode (PW type 5) MUST be used for the packet PW. Ethernet Raw Mode (PW type 5) MUST be used for the packet PW.
skipping to change at page 7, line 51 skipping to change at page 7, line 51
[RFC5342] to this protocol (PacketPWEthA and PacketPWEthB). [RFC5342] to this protocol (PacketPWEthA and PacketPWEthB).
PacketPWEthA is the value lower Ethernet address and PacketPWEthB is PacketPWEthA is the value lower Ethernet address and PacketPWEthB is
the higher value Ethernet address. Where [RFC4447] signalling is the higher value Ethernet address. Where [RFC4447] signalling is
used to set up the PW, the LDP peers compare IP addresses and with used to set up the PW, the LDP peers compare IP addresses and with
the PE with the higher IP address uses PacketPWEthA, whilst the LDP the PE with the higher IP address uses PacketPWEthA, whilst the LDP
peer with the lower IP address uses PacketPWEthB. peer with the lower IP address uses PacketPWEthB.
Where no signalling PW protocol is used, suitable Ethernet addresses Where no signalling PW protocol is used, suitable Ethernet addresses
MUST be configured at each PE. MUST be configured at each PE.
Not withstanding the fact that this PW represents a point to point Not withstanding the fact that this PW represents a point-to-point
connection, some client layer protocols require the use of a connection, some client layer protocols require the use of a
destination multicast address in the Ethernet encapsulation. This destination multicast address in the Ethernet encapsulation. This
mode of operation MUST be supported. mode of operation MUST be supported.
6. Ethernet Functional Restrictions 6. Ethernet Functional Restrictions
The use of Ethernet as the encapsulation mechanism for traffic The use of Ethernet as the encapsulation mechanism for traffic
between the server LSRs is a convenience based on the widespread between the server LSRs is a convenience based on the widespread
availability of existing hardware. In this application there is no availability of existing hardware. In this application there is no
requirement for any Ethernet feature other than its protocol requirement for any Ethernet feature other than its protocol
multiplexing capability. Thus, for example, the Ethernet OAM is NOT multiplexing capability. Thus, for example, the Ethernet OAM is NOT
REQUIRED. REQUIRED.
The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q
between PEs is not supported. between PEs is not supported.
Point to multipoint and multipoint to multipoint operation of the Point-to-multipoint and multipoint-to-multipoint operation of the
virtual Ethernet is not supported. virtual Ethernet is not supported.
7. Congestion Considerations 7. Congestion Considerations
A packet pseudowire is normally used to carry IP, MPLS and their A packet pseudowire is normally used to carry IP, MPLS and their
associated support protocols over an MPLS network. There are no associated support protocols over an MPLS network. There are no
congestion considerations beyond those that ordinarily apply to an IP congestion considerations beyond those that ordinarily apply to an IP
or MPLS network. Where the packet protocol being carried is not IP or MPLS network. Where the packet protocol being carried is not IP
or MPLS and the traffic volumes are greater than that ordinarily or MPLS and the traffic volumes are greater than that ordinarily
associated with the support protocols in an IP or MPLS network, the associated with the support protocols in an IP or MPLS network, the
congestion considerations being developed for PWs apply [RFC3985], congestion considerations developed for PWs apply [RFC3985],
[RFC5659]. [RFC5659].
8. Security Considerations 8. Security Considerations
The virtual Ethernet approach to packet PW introduces no new security The virtual Ethernet approach to packet PW introduces no new security
risks. A more detailed discussion of pseudowire security is given in risks. A more detailed discussion of pseudowire security is given in
[RFC3985], [RFC4447] and [RFC3916]. [RFC3985], [RFC4447] and [RFC3916].
9. IANA Considerations 9. IANA Considerations
IANA are requested to allocate two Ethernet unicast addresses from IANA are requested to allocate two Ethernet unicast addresses from
the IANA Ethernet Address Block - Unicast Use the IANA Ethernet Address Block - Unicast Use
Dotted Decimal Description Reference
------------------- ---------------- ---------
Dotted Decimal Description Reference 000.00x.000 PacketPWEthA [This RFC]
----------------------- -------------------------------- --------- 000.00x.001 PacketPWEthB [This RFC]
000.00x.000-000.00x.001 PacketPWEthA and PacketPWEthB [This RFC] The value of x is open for IANA to choose. A value of 3 is suggested.
10. Acknowledgements 10. Acknowledgements
The authors acknowledge the contribution make by Sami Boutros, Giles The authors acknowledge the contribution make by Sami Boutros, Giles
Herron, Siva Sivabalan and David Ward to this document. Herron, Siva Sivabalan and David Ward to this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 10, line 8 skipping to change at page 10, line 19
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
October 2009. October 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010. RFC 5921, July 2010.
Appendix A. Encapsulation Approaches Considered Appendix A. Encapsulation Approaches Considered
A number of approaches to the design of a packet pseudowire (PW) have This appendix is non-normative.
been investigated and have been described at the IETF. This section
discusses the approaches that were analysed and the technical issues A number of approaches to the design of a packet pseudowire (PW) were
that the authors took into consideration in arriving at the proposed investigated by the PWE3 Working Group and were discussed in IETF
approach. meetings and on the PWE3 list. This section describes the approaches
that were analysed and the technical issues that the authors took
into consideration in arriving at the approach described in the main
body of this document. This appendix is provided so that engineers
considering alternative optimizations can have access to the rational
for the selection of the approach described above.
In a typical network there are usually no more that four network In a typical network there are usually no more that four network
layer protocols that need to be supported: IPv4, IPv6, MPLS and CLNS layer protocols that need to be supported: IPv4, IPv6, MPLS and CLNS
although any solution needs to be scalable to a larger number of although any solution needs to be scalable to a larger number of
protocols. The approaches considered in this document all satisfy protocols. The approaches considered in this document all satisfy
this minimum requirement, but vary in their ability to support larger this minimum requirement, but vary in their ability to support larger
numbers of network layer protocols. numbers of network layer protocols.
Additionally it is beneficial if the complete set of protocols Additionally it is beneficial if the complete set of protocols
carried over the network between in support of a set of CE peers fate carried over the network between in support of a set of CE peers fate
 End of changes. 29 change blocks. 
56 lines changed or deleted 71 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/