One document matched: draft-bryant-pwe3-packet-pw-00.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-00.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 a "classic" MPLS network or an MPLS-TP
network <xref target="RFC5317"></xref>. The client may also be either a
"classic" MPLS network of an MPLS-TP network. Considerations as to
whether an MPLS "classic" 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 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="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>
</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 loacl 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="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.5317'?>
<?rfc include='reference.RFC.4385'?>
<?rfc include='reference.RFC.1661'?>
<?rfc include='reference.I-D.ietf-pwe3-segmented-pw'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3985'?>
<?rfc include='reference.RFC.3916'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:44:08 |