One document matched: draft-bryant-pwe3-packet-pw-02.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="std" docName="draft-bryant-pwe3-packet-pw-02.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="2009" />
<area>Internet Area</area>
<workgroup>Network Working Group</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword>
<abstract>
<t>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.</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><!--Look at next taking int a/c section 3.4.1 of TP arch-->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><!--End of look at next....-->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>
<t><figure anchor="PKT-PW-NR">
<preamble></preamble>
<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>
<postamble>MPLS Pseudowire Network Reference Model</postamble>
</figure></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="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>
<t><figure anchor="fwd-model">
<preamble></preamble>
<artwork><![CDATA[ +------------------------------------------------+
| |
| +--------+ +--------+ |
| | | Pkt +-----+ | | |
------+ +---------+ PW1 +--------+ +------
| | Client | AC +-----+ | Server | |
Client | | LSR | | LSR | | Server
Network | | | Pkt +-----+ | | | Network
------+ +---------+ PW2 +--------+ +------
| | | AC +-----+ | | |
| +--------+ +--------+ |
| |
+------------------------------------------------+
]]></artwork>
<postamble>Packet PW Forwarding Model</postamble>
</figure></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="The Protocol Identifier Label">
<t>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 <xref target="PIDLS"></xref>, or is
configured at the ingress PE.</t>
</section>
<section title="Encapsulation ">
<t>The Protocol Stack Reference Model for a packet PW is shown in <xref
target="PStack"></xref> below</t>
<figure anchor="PStack" title="PWE3 Protocol Stack Reference Model">
<artwork><![CDATA[
+-------------+ +-------------+
| Client | | Client |
| network | | network |
| layer | Client Service | layer |
| service |<==============================>| service |
+-------------+ Pseudowire +-------------+
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| Server | | Server |
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>The corresponding packet PW encapsulation is shown in <xref
target="Encap"></xref>.</t>
<figure anchor="Encap"
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>
<postamble></postamble>
</figure>
<t></t>
<t>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 <xref target="RFC5085"></xref>, or by using an ACH indicated using a
generic alert label <xref target="RFC5586"></xref>.</t>
<t>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
it.</t>
</section>
<section title="Packet Pseudowire Control Word">
<t>The packet pseudowire control word (CW) is optional.</t>
<t>Where the CW is used, it conforms to the preferred pseudowire MPLS
control word defined by Figure 2 of <xref target="RFC4385"></xref>. For
reference the packet pseudowire control word is shown in <xref
target="PKT-PW-CW"></xref>. The definitions of the fragmentation (FRG),
length and sequence number fields are to be found in <xref
target="RFC4385"></xref>.</t>
<t><figure anchor="PKT-PW-CW">
<preamble></preamble>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>Packet Pseudowire Control Word</postamble>
</figure></t>
</section>
<section anchor="PIDLS" title="Signaling the PID Label">
<t>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.</t>
<section title="The Protocol FEC Element">
<t>To distribute the PID FEC we define a new FEC element containing
the PID number. This is shown in <xref
target="LDP-PID-FEC-ELM"></xref>.<figure anchor="LDP-PID-FEC-ELM">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>LDP PID FEC Element</postamble>
</figure></t>
<texttable align="left" style="headers">
<preamble>Where</preamble>
<ttcol width="30%">Field</ttcol>
<ttcol>Meaning</ttcol>
<c>Prot</c>
<c>FEC element number 0x83 has been allocated from the IANA registry
"Forwarding Equivalence Class (FEC) Type Name Space" .</c>
<c>Reserved</c>
<c>These reserved bits for future use are to be set to 0 on transmit
and ignored on receive.</c>
<c>Protocol Type</c>
<c>This 16 bit field contain the protocol type as allocated in the
IANA registry "PPP Data Link Layer (DLL) Protocol Numbers"<eref
target="http://www.iana.org/assignments/ppp-numbers"> </eref> <xref
target="RFC1661"></xref>.</c>
</texttable>
<t></t>
</section>
<section title="Procedures to distribute the PID FEC. ">
<t>The LDP procedures defined in <xref target="RFC5036"></xref> 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 <xref
target="RFC5036"></xref>. 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.</t>
</section>
</section>
<section title="Status Indication">
<t>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.</t>
<t>The mechanism described for the mapping of pseudowire status to the
virtual interface state that are described in <xref
target="RFC4447"></xref> and in section 10 of <xref
target="I-D.ietf-pwe3-segmented-pw"></xref> apply to the packet
pseudowire. Pseudowire status messages indicating pseudowire or remote
virtual interface faults MUST be mapped to a fault indication on the
local virtual interface.</t>
</section>
<section title="Setting the load balance label">
<t>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 <xref
target="I-D.ietf-pwe3-fat-pw"></xref> 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 <xref target="FatEncap"></xref>.</t>
<t><figure anchor="FatEncap"
title="Encapsulation of a pseudowire with a pseudowire load balancing label">
<artwork><![CDATA[ +-------------------------------+
| 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)
+-------------------------------+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>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.</t>
<t>The exact specification of the method of selecting an appropriate
load balance label value is outside the scope of this document.</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 layer agreement.</t>
</section>
<section title="Congestion Considerations ">
<t>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 <xref
target="RFC3985"></xref>, <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref>.</t>
</section>
<section title="Security Considerations">
<t>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 <xref target="RFC3985"></xref>, <xref
target="RFC4447"></xref> and <xref target="RFC3916"></xref>.</t>
<t>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 <xref target="RFC4447"></xref>.</t>
</section>
<section title="IANA Considerations ">
<t>Editor's note - the text below was provided to me but I cannot see
the reservation in the registry.</t>
<t>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.</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.4385'?>
<?rfc include='reference.RFC.1661'?>
<?rfc include='reference.RFC.5085'?>
<?rfc include='reference.RFC.5586'?>
<?rfc include='reference.RFC.5036'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3985'?>
<?rfc include='reference.I-D.ietf-pwe3-segmented-pw'?>
<?rfc include='reference.RFC.5317'?>
<?rfc include='reference.RFC.3916'?>
<?rfc include='reference.I-D.ietf-pwe3-fat-pw'?>
<?rfc include='reference.RFC.4448'?>
<?rfc include='reference.I-D.ietf-pwe3-ms-pw-arch'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:44:18 |