Network Working Group S. Bryant, Ed.
Internet-Draft L. Martini
Intended status: Standards Track G. Swallow
Expires: April 24, 2010 Cisco Systems
A. Malis
Verizon Communications
October 21, 2009
Packet Pseudowire Encapsulation over an MPLS PSN
draft-bryant-pwe3-packet-pw-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on April 24, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Bryant, et al. Expires April 24, 2010 [Page 1]
Internet-Draft Packet PW October 2009
Abstract
This document describes a pseudowire 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. For correct
operation these clients require a multi-protocol interface with fate
sharing between the client protocol suite. The packet pseudowire may
be used to carry all of the required layer 2 and layer 3 protocols
between the pair of client LSRs.
Requirements Language
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network Reference Model . . . . . . . . . . . . . . . . . . . 3
3. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Protocol Identifier Label . . . . . . . . . . . . . . . . 6
5. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Packet Pseudowire Control Word . . . . . . . . . . . . . . . . 8
7. Signaling the PID Label . . . . . . . . . . . . . . . . . . . 8
7.1. The Protocol FEC Element . . . . . . . . . . . . . . . . . 8
7.2. Procedures to distribute the PID FEC. . . . . . . . . . . 9
8. Status Indication . . . . . . . . . . . . . . . . . . . . . . 9
9. Setting the load balance label . . . . . . . . . . . . . . . . 10
10. Client Network Layer Model . . . . . . . . . . . . . . . . . . 11
11. Congestion Considerations . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
15.1. Normative References . . . . . . . . . . . . . . . . . . . 12
15.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Bryant, et al. Expires April 24, 2010 [Page 2]
Internet-Draft Packet PW October 2009
1. Introduction
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.
2. Network Reference Model
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
Bryant, et al. Expires April 24, 2010 [Page 3]
Internet-Draft Packet PW October 2009
[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
MPLS Pseudowire Network Reference Model
Figure 1
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.
3. Forwarding Model
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.
Bryant, et al. Expires April 24, 2010 [Page 4]
Internet-Draft Packet PW October 2009
+------------------------------------------------+
| |
| +--------+ +--------+ |
| | | Pkt +-----+ | | |
------+ +---------+ PW1 +--------+ +------
| | Client | AC +-----+ | Server | |
Client | | LSR | | LSR | | Server
Network | | | Pkt +-----+ | | | Network
------+ +---------+ PW2 +--------+ +------
| | | AC +-----+ | | |
| +--------+ +--------+ |
| |
+------------------------------------------------+
Packet PW Forwarding Model
Figure 2
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
Bryant, et al. Expires April 24, 2010 [Page 5]
Internet-Draft Packet PW October 2009
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.
4. The Protocol Identifier Label
Protocol identifier labels (PIDLs) are allocated by the egress PE.
One PIDL is required for each unique protocol type that the egress PE
must forward to its client LSRs. PIDLs MUST be allocated from the
per-platform label space. PIDLs MUST NOT be reserved labels. The
mapping between protocol type and PIDL is either signaled to the
ingress PE using the procedure described in Section 7, or is
configured at the ingress PE.
5. Encapsulation
The Protocol Stack Reference Model for a packet PW is shown in
Figure 3 below
Bryant, et al. Expires April 24, 2010 [Page 6]
Internet-Draft Packet PW October 2009
+-------------+ +-------------+
| Client | | Client |
| network | | network |
| layer | Client Service | layer |
| service |<==============================>| service |
+-------------+ Pseudowire +-------------+
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| Server | | Server |
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
Figure 3: PWE3 Protocol Stack Reference Model
The corresponding packet PW encapsulation is shown in Figure 4.
+-------------------------------+
| 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)
+-------------------------------+
Figure 4: Encapsulation of a pseudowire with a pseudowire load
balancing label
Where the CW is not used another method is needed to multiplex PW OAM
into the PW. This can be accomplished using one of the methods
described in [RFC5085], or by using an ACH indicated using a generic
alert label [RFC5586].
The setting the TTL of an MPLS label is a matter of local policy on a
PE. However when sending the PID label the TTL SHOULD be set to 1 to
avoid forwarding a mis-routed packet beyond the first PE receiving
Bryant, et al. Expires April 24, 2010 [Page 7]
Internet-Draft Packet PW October 2009
it.
6. Packet Pseudowire Control Word
The packet pseudowire control word (CW) is optional.
Where the CW is used, it conforms to the preferred pseudowire MPLS
control word defined by Figure 2 of [RFC4385]. For reference the
packet pseudowire control word is shown in Figure 5. The definitions
of the fragmentation (FRG), length and sequence number fields are to
be found in [RFC4385].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet Pseudowire Control Word
Figure 5
7. Signaling the PID Label
To signal the label binding between an MPLS label, and the desired
PIDL the new Label Distribution protocol (LDP) Forwarding Equivalence
Class (FEC) element is defined below is used.
7.1. The Protocol FEC Element
To distribute the PID FEC we define a new FEC element containing the
PID number. This is shown in Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prot (0x83) | Reserved | Protocol type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LDP PID FEC Element
Bryant, et al. Expires April 24, 2010 [Page 8]
Internet-Draft Packet PW October 2009
Figure 6
Where
Field Meaning
--------------- -----------------------------------------------------
Prot FEC element number 0x83 has been allocated from the
IANA registry "Forwarding Equivalence Class (FEC)
Type Name Space" .
Reserved These reserved bits for future use are to be set to 0
on transmit and ignored on receive.
Protocol Type This 16 bit field contain the protocol type as
allocated in the IANA registry "PPP Data Link Layer
(DLL) Protocol
Numbers"<http://www.iana.org/assignments/ppp-numbers>
[RFC1661].
7.2. Procedures to distribute the PID FEC.
The LDP procedures defined in [RFC5036] are used to distribute the
PID label binding to the protocol ID type. The LDP liberal label
retention independent mode is used to distribute the PID label
bindings, however the LDP Label request procedures MUST also be
supported for the PID label FEC as required by [RFC5036]. Once a
Protocol FEC label mapping is advertised by a PE, it will be used for
all packet PWs that require that protocol. A PE MUST mark a local
virtual interface as faulted if the PE has not received a remote
label binding for a protocol that is configured on the interface.
Similarly, if a label withdraw is received for a particular protocol,
all virtual interfaces using packet PWs that have that specific
protocol configured MUST receive the appropriate fault condition.
This FEC MUST only be used in conjunction with the packet PW, and
MPLS packets containing only the advertised MPLS label MUST NOT be
sent to the PE that advertised this FEC. The use of this FEC element
without the packet PW label is undefined.
8. Status Indication
A pseudowire status indicating a fault can be considered equivalent
to interface down and SHOULD be passed across the virtual interface
to the local LSR. This improves scaling in PE with large numbers of
co-resident LSRs and with LSRs that have large numbers of interfaces
mapped to pseudowires.
The mechanism described for the mapping of pseudowire status to the
virtual interface state that are described in [RFC4447] and in
section 10 of [I-D.ietf-pwe3-segmented-pw] apply to the packet
Bryant, et al. Expires April 24, 2010 [Page 9]
Internet-Draft Packet PW October 2009
pseudowire. Pseudowire status messages indicating pseudowire or
remote virtual interface faults MUST be mapped to a fault indication
on the local virtual interface.
9. Setting the load balance label
The client service may wish the packet PW to take advantage of any
Equal Cost Multi-Path (ECMP) support in the server layer. In this
case a load balance label as described in [I-D.ietf-pwe3-fat-pw] may
be included in the MPLS label stack. Indeed without this feature
there will be significant polarization of the traffic in the network,
since most of the client traffic will be either MPLS or IP and
therefore most of the traffic between a pair of PEs will be carried
with the same pair of bottom of stack labels. The FAT label must be
inserted at the bottom of stack, i.e. below the PIDL as shown in
Figure 7.
+-------------------------------+
| Client |
| Network Layer |
| packet | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| FAT Label (S=1) | 4 octets
+-------------------------------+
| PID Label (S=0) | 4 Octets
+-------------------------------+
| PW label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)
+-------------------------------+
Figure 7: Encapsulation of a pseudowire with a pseudowire load
balancing label
Where the client service is MPLS it would be appropriate to copy the
client layer, bottom of stack MPLS label into the FAT label. Where
the client layer is IP the FAT label would typically be calculated by
hashing on the source and destination addresses, the protocol ID and
higher-layer flow-dependent fields such as TCP/UDP ports, L2TPv3
Session ID's etc.
Bryant, et al. Expires April 24, 2010 [Page 10]
Internet-Draft Packet PW October 2009
The exact specification of the method of selecting an appropriate
load balance label value is outside the scope of this document.
10. Client Network Layer Model
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 layer agreement.
11. Congestion Considerations
This 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],
[I-D.ietf-pwe3-ms-pw-arch].
12. Security Considerations
The packet pseudowire provides no means of protecting the contents or
delivery of the pseudowire packets on behalf of the client packet
service. The packet pseudowire may, however, leverage security
mechanisms provided by the MPLS Tunnel Layer. A more detailed
discussion of pseudowire security is given in [RFC3985], [RFC4447]
and [RFC3916].
The Protocol FEC, and corresponding label is only used in the context
of a packet PW, and it does not change the security implications
already discussed in [RFC4447].
13. IANA Considerations
Editor's note - the text below was provided to me but I cannot see
Bryant, et al. Expires April 24, 2010 [Page 11]
Internet-Draft Packet PW October 2009
the reservation in the registry.
A FEC element allocation of 0x83 has already be made by IANA.
However, IANA are requested to up date the registry "Forwarding
Equivalence Class (FEC) Type Name Space" with a reference to this RFC
number once the number is allocated.
14. Acknowledgements
The authors acknowledge the contribution make by Sami Boutros, Giles
Herron, Siva Sivabalan and David Ward to this document.
15. References
15.1. Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[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.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
15.2. Informative References
[I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS PSN", draft-ietf-pwe3-fat-pw-01 (work in
Bryant, et al. Expires April 24, 2010 [Page 12]
Internet-Draft Packet PW October 2009
progress), September 2009.
[I-D.ietf-pwe3-ms-pw-arch]
Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge",
draft-ietf-pwe3-ms-pw-arch-07 (work in progress),
July 2009.
[I-D.ietf-pwe3-segmented-pw]
Martini, L., Nadeau, T., Metz, C., Duckett, M., Bocci, M.,
Balus, F., and M. Aissaoui, "Segmented Pseudowire",
draft-ietf-pwe3-segmented-pw-13 (work in progress),
August 2009.
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009.
Authors' Addresses
Stewart Bryant (editor)
Cisco Systems
250, Longwater, Green Park,
Reading, Berks RG2 6GB
UK
Email: stbryant@cisco.com
Bryant, et al. Expires April 24, 2010 [Page 13]
Internet-Draft Packet PW October 2009
Luca Martini
Cisco Systems
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
USA
Email: lmartini@cisco.com
George Swallow
Cisco Systems
1414 Massachusetts Ave
Boxborough, MA 01719
USA
Email: swallow@cisco.com
URI:
Andy Malis
Verizon Communications
117 West St.
Waltham, MA 02451
USA
Email: andrew.g.malis@verizon.com
Bryant, et al. Expires April 24, 2010 [Page 14]