One document matched: draft-bryant-pwe3-packet-pw-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="bcp" docName="draft-bryant-pwe3-packet-pw-03.txt"
ipr="trust200902">
<front>
<title abbrev="Packet PW">Packet Pseudowire Encapsulation over an MPLS
PSN</title>
<author fullname="Stewart Bryant" initials="S" role="editor"
surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater, Green Park,</street>
<city>Reading</city>
<region>Berks</region>
<code>RG2 6GB</code>
<country>UK</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Luca Martini" initials="L" surname="Martini">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>9155 East Nichols Avenue, Suite 400</street>
<city>Englewood</city>
<region>CO</region>
<code>80112</code>
<country>USA</country>
</postal>
<email>lmartini@cisco.com</email>
</address>
</author>
<author fullname="George Swallow" initials="G" surname="Swallow">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Massachusetts Ave</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<email>swallow@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Andy Malis" initials="A" surname="Malis">
<organization>Verizon Communications</organization>
<address>
<postal>
<street>117 West St.</street>
<city>Waltham</city>
<region>MA</region>
<code>02451</code>
<country>USA</country>
</postal>
<email>andrew.g.malis@verizon.com</email>
</address>
</author>
<date year="2010" />
<area>Internet Area</area>
<workgroup>Network Working Group</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction ">
<t>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 <xref target="RFC5317"></xref>. 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.</t>
<t>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 <xref
target="RFC3985"></xref>. 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).</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Network Reference Model">
<t>The network reference model for the packet pseudowire operating in an
MPLS network is shown in <xref target="PKT-PW-NR"></xref>. This is an
extension of Figure 3 "Pre-processing within the PWE3 Network Reference
Model" from <xref target="RFC3985"></xref>.</t>
<figure anchor="PKT-PW-NR">
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t></t>
<t>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.</t>
</section>
<section title="Client Network Layer Model">
<t>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.</t>
</section>
<section title="Forwarding Model">
<t>The packet PW forwarding model is illustrated in <xref
target="fwd-model"></xref>. 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.</t>
<figure anchor="fwd-model" title="Packet PW Forwarding Model">
<artwork><![CDATA[
+------------------------------------------------+
| |
| +--------+ +--------+ |
| | | Pkt +-----+ | | |
------+ +---------+ PW1 +--------+ +------
| | Client | AC +-----+ | Server | |
Client | | LSR | | LSR | | Server
Network | | | Pkt +-----+ | | | Network
------+ +---------+ PW2 +--------+ +------
| | | AC +-----+ | | |
| +--------+ +--------+ |
| |
+------------------------------------------------+
]]></artwork>
</figure>
<t></t>
<t>A packet PW PE comprises three components, the client LSR, PW
processor and a server LSR. Note that <xref target="RFC3985"></xref>
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.</t>
<t>It may be useful to first recall the operation of a layer two PW such
as an Ethernet PW <xref target="RFC4448"></xref> 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.</t>
<t>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 <xref target="RFC3985"></xref>. 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.</t>
<t>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.</t>
<t>Note that the semantics of the PW between the client LSRs is a point
to point link.</t>
</section>
<section title="Design Considerations">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Encapsulation Approaches Considered">
<t>There are four candidate approaches that have been analysed:</t>
<t><list style="numbers">
<t>A protocol identifier (PID) in the PW Control Word (CW)</t>
<t>A PID label</t>
<t>Parallel PWs - one per protocol.</t>
<t>Virtual Ethernet</t>
</list></t>
<section title="A Protocol Identifier in the Control Word">
<t>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
<xref target="RFC5385"></xref> 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.</t>
<t>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.</t>
</section>
<section title="PID Label ">
<t>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
<xref target="PEn"></xref>. </t>
<figure anchor="PEn"
title="Encapsulation of a pseudowire with a pseudowire load balancing label">
<artwork><![CDATA[
+-------------------------------+
| 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)
+-------------------------------+
]]></artwork>
</figure>
<t anchor="PIDLEncap"></t>
<t>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 and is the approach described in Section 3.4.3
of <xref target="I-D.ietf-mpls-tp-framework"></xref> . </t>
<t>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.</t>
</section>
<section title="Parallel PWs">
<t>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.</t>
<t>The are a number of serious downsides with this approach:</t>
<t><list style="numbers">
<t>From an operational point of view the lack of fate sharing
between the protocol types can lead to complex faults which are
difficult to diagnose. </t>
<t>There is an undesirable trade off in the OAM related to the
first point. Either we would have to run an OAM on each PW and
bind them together which lead to significant protocol and software
complexity and does not scale well. Alternatively we would need to
run a single OAM session on one of the PWs as a proxy for the
others and the diagnose any more complex failure on a case by case
basis. To some extent the issue of fate sharing between protocol
in the bundle (for example the assumed fate sharing between CLNS
and IP in IS-IS) can be mitigated through the use of BFD.</t>
<t>The need to configure manage and synchronize the behaviour of a
group of PWs as if they were a single PW leads to an increase in
control plane complexity.</t>
</list></t>
<t>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.
</t>
</section>
<section title="Virtual Ethernet">
<t>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 <xref target="RFC4448"></xref> 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. </t>
<t>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. </t>
<t>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.</t>
</section>
<section title="Recommended Encapsulation">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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. </t>
</section>
</section>
<section title="Packet PW Encapsulation ">
<t>The client network work layer packet encapsulation into a packet PW
is shown in <xref target="pktPWps"></xref>.</t>
<figure anchor="pktPWps">
<artwork><![CDATA[ +-------------------------------+
| Client |
| Network Layer |
| packet | n octets
| |
+-------------------------------+
| |
| Ethernet | 14 octets
| Header |
| +---------------+
| |
+---------------+---------------+
| Optional Control Word | 4 octets
+-------------------------------+
| Optional FAT Label (S=1) | 4 octets
+-------------------------------+
| PW label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)
+-------------------------------+
]]></artwork>
</figure>
<t></t>
<t>This conforms to the PW protocols stack as defined in <xref
target="RFC4448"></xref> and</t>
<t><xref target="I-D.ietf-pwe3-fat-pw"></xref>.</t>
<t>This 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 <xref
target="RFC4448"></xref></t>
<t>Considerations concerning the allocation of a suitable Ethernet
address the virtual Ethernet will be discussed in a future version of
this document.</t>
</section>
<section title="Ethernet Functional Restrictions">
<t>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.</t>
<t>The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q
between PEs will be discussed in a future revision.</t>
<t>Point to multipoint and multipoint to multipoint operation of the
virtual Ethernet is not supported.</t>
</section>
<section title="Congestion Considerations ">
<t>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 <xref
target="RFC3985"></xref>, <xref target="RFC5659"></xref>.</t>
</section>
<section title="Security Considerations">
<t>The virtual Ethernet approach to packet PW introduces no new security
risks. A more detailed discussion of pseudowire security is given in
<xref target="RFC3985"></xref>, <xref target="RFC4447"></xref> and <xref
target="RFC3916"></xref>.</t>
</section>
<section title="IANA Considerations ">
<t>This section may be removed on publication.</t>
<t>There are no IANA action required by the publication of this
document.</t>
</section>
<section title="Acknowledgements">
<t>The authors acknowledge the contribution make by Sami Boutros, Giles
Herron, Siva Sivabalan and David Ward to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.4447'?>
<?rfc include='reference.RFC.4448'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3985'?>
<?rfc include='reference.RFC.5317'?>
<?rfc include='reference.RFC.3916'?>
<?rfc include='reference.I-D.ietf-pwe3-fat-pw'?>
<?rfc include='reference.RFC.5659'?>
<?rfc include='reference.RFC.5385'?>
<?rfc include='reference.I-D.ietf-mpls-tp-framework'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:12 |