One document matched: draft-bryant-pwe3-packet-pw-01.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-01.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>
<phone>UK</phone>
<facsimile></facsimile>
<email>stbryant@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Sami Boutros" initials="S" surname="Boutros">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3750 Cisco Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>sboutros@cisco.com</email>
<uri></uri>
</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>
<phone></phone>
<facsimile></facsimile>
<email>lmartini@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Siva Sivabalan" initials="S" surname="Sivabalan">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>2000 Innovation Drive</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 3EB</code>
<country>Canada</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>msiva@cisco.com</email>
<uri></uri>
</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>
<phone></phone>
<facsimile></facsimile>
<email>swallow@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="David Ward" initials="D " surname="Ward">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3750 Cisco Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>wardd@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>
<phone></phone>
<facsimile></facsimile>
<email>andrew.g.malis@verizon.com</email>
<uri></uri>
</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 as to whether an unrestricted MPLS network can act 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 to attach the
clients to the PEs, and a pseudowire 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 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 (e.g. Cisco Discovery
Protocol). 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 LSRs and server PEs are 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 PW PE comprises two components, the PW processor and an LSR. On
receipt of a packet from the attachment circuit (AC) the PW undertakes
any header processing, pushes the CW and pushes the PW label. It then
passes the packet to an LSR which pushes the label needed to reach the
egress PE. 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 by the LSR. The PW instance performs any required
reconstruction using the CW and passes the packet directly to the
attachment circuit.</t>
<t>In the packet PW case an LSR belonging to the client layer is
embedded within the equipment. This determines the next hop in the
client layer, pushes the label needed by the client next hop, and passes
the packet to the correct PW instance indicating the packet protocol
type. The PW instance pushes CW (which included the protocol
identifier), pushes the PW label and passes the packet to the server LSR
for forwarding to the egress PW PE. At the egress PE, the packet
typically arrives with the PW label at the top of stack, the packet is
thus directed to the correct PW instance by the server LSR. This removes
the CW and passes the packet to the client LSR indicating the protocol
type. The client LSR then forwards the packet based on the top label,
which is a client layer label.</t>
<t>Note that although the description above is written in terms of the
behaviour of an MPLS LSR, the processing would model would be the same
for IP.</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 encapsulation of a packet PW is shown in <xref
target="Encap"></xref> below</t>
<figure anchor="Encap"
title="Encapsulation of a pseudowire with a pseudowire load balancing label">
<artwork><![CDATA[
+-------------------------------+
| MPLS Tunnel label(s) | n*4 octets (four octets per label)
+-------------------------------+
| PW label | 4 octets
+-------------------------------+
| Control Word | 6 octets
+-------------------------------+
| Client |
| Network Layer |
| packet | n octets
| |
+-------------------------------+
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
</section>
<section title="Packet Pseudowire Control Word">
<t>This section describes the encapsulation of a packet pseudowire. The
packet pseudowire always uses the control word. The control word
consists of two components: the preferred pseudowire MPLS control word
<xref target="RFC4385"></xref>, immediately followed by a PPP data link
layer (DLL) protocol number <xref target="RFC1661"></xref>. The 16 bit
format of the PPP DLL protocol number MUST be used.</t>
<t>The MPLS pseudowire control word is shown in <xref
target="PKT-PW-CW"></xref>. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble>Packet Pseudowire Control Word</postamble>
</figure></t>
<t>Note that the PPP link control protocol is not used.</t>
<t>Where the packet service being supported is a network layer service
such as MPLS or IP, only a best effort packet ordering is normally
required. The sequence number would therefore normally be set to zero
(no PW sequence number processing). </t>
</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
c-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 a load
balance label as described in <xref
target="I-D.ietf-pwe3-fat-pw"></xref> may be included in the MPLS label
stack. Where the client service is MPLS it would be appropriate to copy
the client layer, bottom of stack MPLS label into the load balance
label. Where the client layer is IP the load balance 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 being used to carry MPLS and its associated
support protocols over an MPLS network. There are no congestion
considerations beyond those that ordinarily apply to an MPLS
network.</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>
</section>
<section title="IANA Considerations ">
<t>IANA are requested to allocate a new pseudowire type for packet
pseudowire in the MPLS Pseudowire Types Registry. The next available
value is requested.</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'?>
</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'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:51 |