| Network Working Group | S. Bryant, Ed. |
| Internet-Draft | L. Martini |
| Intended status: Best Current Practice | G. Swallow |
| Expires: January 09, 2012 | Cisco Systems |
| A. Malis | |
| Verizon Communications | |
| July 08, 2011 |
Packet Pseudowire Encapsulation over an MPLS PSN
draft-ietf-pwe3-packet-pw-01.txt
This document describes a pseudowire mechanism that is used to 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. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 09, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 networks. The server MPLS network may be an MPLS network or a network conforming to the MPLS-TP [RFC5317]. The client may also be either a MPLS network of a network conforming to the MPLS-TP. Considerations regarding the use of an MPLS network 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 physical interface, the same data-link type MUST be used to attach 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 reason that inter-working between different physical and data-link attachment types is specifically disallowed in the pseudowire architecture is because this is a complex task and not a simple bit-mapping exercise. The inter-working is not limited to the physical and data-link interfaces and the state-machines. It also requires a compatible approach to the formation of the adjacencies between attached client network equipment. As an example the reader should consider the differences between router adjacency formation on a point to point link compared to a multi-point to multi-point interface (e.g. Ethernet).
A further consideration is that two adjacent MPLS LSRs do not simply exchange MPLS packets. They exchange IP packets for adjacency formation, control, routing, label exchange, management and monitoring purposes. In addition they may exchange data-link packets as part of routing (e.g. IS-IS hellos and IS-IS LSPs) and for OAM purposes such as Link Layer Discovery protocol [IEEE standard 802.1AB-2009]. Thus the two clients require an attachment mechanism that can be used to multiplex a number of 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 equipment, the data-link layer can be simplified to a simple protocol identifier (PID) that is used to multiplex the various data-link types onto a pseudowire. This is the method that described in this document.
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 "Pre-processing within the PWE3 Network Reference Model" from [RFC3985].
PW PW
End Service End Service
| |
|<------- Pseudowire ------->|
| |
| Server |
| |<- PSN Tunnel ->| |
| V V |
------- +-----+-----+ +-----+-----+ -------
) | | |================| | | (
client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client
MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN
) | | | | | | (
) | | |================| | | (
------- +-----+-----+ +-----+-----+ --------
^ ^
| |
| |
|<---- Emulated Service----->|
| |
Virtual physical Virtual physical
termination termination
In this model LSRs, LSR1 and LSR2, are part of the client MPLS packet switched network (PSN). The PEs, PE1 and PE2 are part of the server PSN, that is to be used to provide connectivity between the client LSRs. The attachment circuit that is used to connect the MPLS LSRs to the PEs is a virtual interface within the equipment. A packet pseudowire is used to provide connectivity between these virtual interfaces. This packet pseudowire is used to transport all of the required layer 2 and layer 3 between protocols between LSR1 and LSR2.
The packet PW appears as a single point to point link to the client layer. Network Layer adjacency formation and maintenance between the client equipments will the follow normal practice needed to support the required relationship in the client layer. The assignment of 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 assigned by appropriate configuration of the embedded client network 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 the operator of the client network to ensure that the server layer operator provides the necessary service level agreement.
The packet PW forwarding model is illustrated in Figure 2. The forwarding operation can be likened to a virtual private network (VPN), in which a forwarding decision is first taken at the client layer, an encapsulation is applied and then a second forwarding decision is taken at the server layer.
+------------------------------------------------+
| |
| +--------+ +--------+ |
| | | Pkt +-----+ | | |
------+ +---------+ PW1 +--------+ +------
| | Client | AC +-----+ | Server | |
Client | | LSR | | LSR | | Server
Network | | | Pkt +-----+ | | | Network
------+ +---------+ PW2 +--------+ +------
| | | AC +-----+ | | |
| +--------+ +--------+ |
| |
+------------------------------------------------+
A packet PW PE comprises three components, the client LSR, PW processor and a server LSR. Note that [RFC3985] does not formally indicate the presence of the server LSR because it does not concern itself with the server layer. However it is useful in this document to recognise that the server LSR exists.
It may be useful to first recall the operation of a layer two PW such as an Ethernet PW [RFC4448] within this model. The client LSR is not present and packets arrive directly on the attachment circuit (AC) which is part of the client network. The PW undertakes any header processing, if configured to do so, it then pushes 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 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 typically arrives with the PW label at top of stack, the packet is thus directed to the correct PW instance. The PW instance performs any required reconstruction using, if necessary, the CW and the packet is sent directly to the attachment circuit.
Now let us consider the case client layer MPLS traffic being carried over a packet PW. An LSR belonging to the client layer is embedded within the PE equipment. This is a type of native service processing element [RFC3985]. This LSR determines the next hop in the client layer, and pushes the label needed by the next hop in the client layer. It then passes the packet to the correct PW instance indicating the packet protocol type. If the PW is configured to require a CW this is pushed. The PW instance then examines the protocol type and pushes a label that identifies the protocol type to the egress PE. The PW instance then proceeds as it would for a layer two PW, by pushing the PW label and then handing the packet to the server layer LSR for delivery. At egress, the packet again arrives with the PW label at the top of stack which causes the packet to be passed to the correct PW instance. This PW instance knows that the PW type is a packet PW, and hence that it needs to interpret the next label as a protocol type identifier. If necessary the CW is then popped and processed. The packet is then passed to the egress client LSR together with information that identifies the packet protocol type. The egress client LSR then forwards the packet in the normal manner for a protocol of that type.
Note that although the description above is written in terms of the behaviour of an MPLS LSR, the processing model would be similar for an IP packet, or indeed any other protocol type.
Note that the semantics of the PW between the client LSRs is a point to point link.
The client network work layer packet encapsulation into a packet PW is shown in Figure 3.
+-------------------------------+ | Client | | Network Layer | | packet | n octets | | +-------------------------------+ | | | Ethernet | 14 octets | Header | | +---------------+ | | +---------------+---------------+ | Optional Control Word | 4 octets +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) +-------------------------------+
This conforms to the PW protocols stack as defined in [RFC4448]. The protocol stack is unremarkable except to note that the stack does not retain 32 bit alignment between the virtual Ethernet header and the 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 alignment is necessary to preserve backwards compatibility with the Ethernet PW design [RFC4448]
Ethernet Raw Mode (PW type 5) MUST be used for the packet PW.
The PEs MAY use a local Ethernet address for the Ethernet header used to encapsulate the client network layer packet. Alternatively the PEs may use the following proceedure.
IANA are requested to allocate two unicast Ethernet addresses [RFC5342] to this protocol (PacketPWEthA and PacketPWEthB). PacketPWEthA is the value lower Ethernet address and PacketPWEthB is the higher value Ethernet address. Where [RFC4447] signalling is 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 peer with the lower IP address uses PacketPWEthB.
Where no signalling PW protocol is used, suitable Ethernet addresses MUST be configured at each PE.
Not withstanding the fact that this PW represents a point to point connection, some client layer protocols require the use of a destination mulitcast address in the Ethernet encapsulation. This mode of operation MUST be supported.
The use of Ethernet as the encapsulation mechanism for traffic between the server LSRs is a convenience based on the widespread availability of existing hardware. In this application there is no requirement for any Ethernet feature other than its protocol multiplexing capability. Thus, for example, the Ethernet OAM is NOT REQUIRED.
The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q between PEs is not supported.
Point to multipoint and multipoint to multipoint operation of the virtual Ethernet is not supported.
A packet pseudowire is normally used to carry IP, MPLS and their associated support protocols over an MPLS network. There are no congestion considerations beyond those that ordinarily apply to an IP or MPLS network. Where the packet protocol being carried is not IP or MPLS and the traffic volumes are greater than that ordinarily associated with the support protocols in an IP or MPLS network, the congestion considerations being developed for PWs apply [RFC3985], [RFC5659].
The virtual Ethernet approach to packet PW introduces no new security risks. A more detailed discussion of pseudowire security is given in [RFC3985], [RFC4447] and [RFC3916].
IANA are requested to allocate two Ethernet unicast addresses from the IANA Ethernet Aaddress Block - Unicast Use
Dotted Decimal Description Reference ----------------------- -------------------------------- --------- 000.00x.000-000.00x.001 PacketPWEthA and PacketPWEthB [This RFC]
The authors acknowledge the contribution make by Sami Boutros, Giles Herron, Siva Sivabalan and David Ward to this document.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4447] | Martini, L., Rosen, E., El-Aawar, N., Smith, T. and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. |
| [RFC4448] | Martini, L., Rosen, E., El-Aawar, N. and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. |
| [RFC5342] | Eastlake, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008. |
| [RFC3985] | Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. |
| [RFC5317] | Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009. |
| [RFC3916] | Xiao, X., McPherson, D. and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. |
| [RFC5659] | Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009. |
| [RFC5385] | Touch, J., "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", RFC 5385, February 2010. |
| [RFC5921] | Bocci, M., Bryant, S., Frost, D., Levrau, L. and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. |
A number of approaches to the design of a packet pseudowire (PW) have been investigated and have been described at the IETF. This section discusses the approaches that were analysed and the technical issues that the authors took into consideration in arriving at the proposed approach.
In a typical network there are usually no more that four network layer protocols that need to be supported: IPv4, IPv6, MPLS and CLNS although any solution needs to be scalable to a larger number of protocols. The approaches considered in this document all satisfy this minimum requirement, but vary in their ability to support larger numbers of network layer 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 share. It is additionally beneficial if a single OAM session can be used to monitor the behaviour of this complete set. During the investigation various views were expressed as to where on the scale from absolutely required to "nice to have" these benefits lay, but in the end they were not a factor in reaching our conclusion.
There are four candidate approaches that have been analysed:
This is the approach that we proposed in draft 0 of this document . The proposal was that a Protocol Identifier (PID) would included in the PW control word (CW), by appending it to the generic control word [RFC5385] to make a 6 byte CW (the version 0 draft actually included two reserved bytes to provide 32bit alignment, but let us assume that was optimized out). A variant of this is just to use a 2 byte PID without a control word.
This is a simple approach, and is basically a virtual PPP interface without the PPP control protocol. This has a smaller MTU than for example a virtual Ethernet would need, however in forwarding terms it is not as simple as the PID label or multiple PW approaches described next, and may not be deployable on a number of existing hardware platforms.
This is the approach that we described in Version 2 of this document. The in this mechanism the PID is indicated by including a label after the PW label that indicates the protocol type as shown in Figure 5.
+-------------------------------+ | Client | | Network Layer | | packet | n octets | | +-------------------------------+ | Optional Control Word | 4 octets +-------------------------------+ | PID Label (S=1) | 4 Octets +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) +-------------------------------+
In the PID Label approach a new Label Distribution protocol (LDP) Forwarding Equivalence Class (FEC) element is used to signal the mapping between protocol type and the PID label. This approach complies with RFC3031.
A similar approach to PID label is described in Section 3.4.5 of [RFC5921]. In this case when the client is a network layer packet service such as IP or MPLS, a service label and demultiplexer label (which may be combined) is used to provide the necessary identifications needed to carry this traffic over an LSP.
The authors surveyed the hardware designs produced by a number of companies across the industry and concluded that whilst the approach complies with the MPLS architecture, it may conflict with a number of designer's interpretation of the existing MPLS architecture. This led to concerns that the approach may result in unexpected difficulties in the future. Specifically there is an assumption in many designs that a forwarding decision should be made on the basis of a single label. Whilst the approach is attractive, it cannot be supported by many commodity chip sets and this would require new hardware which would increase the cost of deployment and delay the introduction of a packet PW service.
In this approach one PW is constructed for each protocol type that must be carried between the PEs. Thus a complete packet PW would therefore consist of a bundle of PWs . This model would be very simple and efficient from a forwarding point of view. The number of parallel PWs required would normally be relatively small. In a typical network there are usually no more that four network layer protocols that need to be supported: IPv4, IPv6, MPLS and CLNS although any solution needs to be scalable to a larger number of protocols.
The are a number of serious downsides with this approach:
The Parallel PW mechanism is therefore an approach which simplifies the forwarding plane, but only at a cost of a considerable increase in other aspects of the design and in particular operation of the PW.
Using a virtual Ethernet to provide a packet PW would require PEs to include a virtual (internal) Ethernet interface and then to use an Ethernet PW [RFC4448] to carry the user traffic. This is conceptually simple and can be implemented today without any further standards action, although there are a number of applicability considerations that it is useful to draw to the attention of the community.
Conceptually this is a simple approach and some deployed equipments can already do this. However the requirement to run a complete Ethernet adjacency lead us to conclude that there was a need to identify a simpler approach. The packets encapsulated in an Ethernet header have a larger MTU than the other approaches, although this is not considered to be an issue on the networks needing to carry packet PWs.
The virtual Ethernet mechanism was the first approach that the authors considered, before the merits of the other approaches appeared to make them more attractive. As we shall see below however, the other approaches were not without issues and it appears that the virtual Ethernet is preferred approach to providing a packet PW.
The operational complexity and the breaking of fate sharing assumptions associated with the parallel PW approach would suggest that this is not an approach that should be further pursued.
The PID Label approach gives rise to the concerns that it will break implicit behavioural and label stack size assumptions in many implementations. Whilst those assumptions may be addressed with new hardware this would delay the introduction of the technology to the point where it was unlikely to gain acceptance in competition with an approach that needed no new protocol design and is already supportable on many existing hardware platforms.
The PID in the CW leads to the most compact protocol stack, is simple and requires minimal protocol work. However it is a new forwarding design, and apart from the issue of the larger packet header and the simpler adjacency formation offers no advantage over the virtual Ethernet.
The above considerations bring us back to the virtual Ethernet, which is a well known protocol stack, with a well known (internal) client interface. It is already implemented in many hardware platforms and is therefore readily deployable. The authors conclude that having considered a number of initially promising alternatives, the simplicity and existing hardware make the virtual Ethernet approach to the packet PW the most attractive solution.