Network Working Group S. Bryant, Ed.
Internet-Draft S. Boutros
Intended status: Standards Track L. Martini
Expires: August 31, 2009 S. Sivabalan
G. Swallow
D . Ward
Cisco Systems
A. Malis
Verizon Communications
February 27, 2009
Packet Pseudowire Encapsulation over an MPLS PSN
draft-bryant-pwe3-packet-pw-00.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 August 31, 2009.
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 August 31, 2009 [Page 1]
Internet-Draft Packet PW February 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. Packet Pseudowire Control Word . . . . . . . . . . . . . . . . 4
4. Status Indication . . . . . . . . . . . . . . . . . . . . . . . 5
5. Congestion Considerations . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Bryant, et al. Expires August 31, 2009 [Page 2]
Internet-Draft Packet PW February 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 a "classic" MPLS network or
an MPLS-TP network [RFC5317]. 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.
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 [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
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 (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.
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.
2. Network Reference Model
The network reference model for the packet pseudowire is shown in
Figure 1. This is an extension of Figure 3 "Pre-processing within
the PWE3 Network Reference Model" from [RFC3985].
Bryant, et al. Expires August 31, 2009 [Page 3]
Internet-Draft Packet PW February 2009
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. Packet Pseudowire Control Word
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 [RFC4385], immediately followed by a PPP data link layer (DLL)
protocol number [RFC1661]. The 16 bit format of the PPP DLL protocol
number MUST be used.
The MPLS pseudowire control word is shown in Figure 2. Definitions
Bryant, et al. Expires August 31, 2009 [Page 4]
Internet-Draft Packet PW February 2009
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet Pseudowire Control Word
Figure 2
Note that the PPP link control protocol is not used.
4. 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 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.
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
pseudowire. Pseudowire status messages indicating pseudowire or
remote virtual interface faults MUST be mapped to a fault indication
on the local virtual interface.
5. Congestion Considerations
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.
6. Security Considerations
The packet pseudowire provides no means of protecting the contents or
delivery of the pseudowire packets on behalf of the client packet
Bryant, et al. Expires August 31, 2009 [Page 5]
Internet-Draft Packet PW February 2009
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].
7. IANA Considerations
IANA are requested to allocate a new pseudowire type for packet
pseudowire in the MPLS Pseudowire Types Registry. The next available
value is requested.
8. References
8.1. Normative References
[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-11 (work in progress),
February 2009.
[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.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009.
8.2. Informative References
[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-
Bryant, et al. Expires August 31, 2009 [Page 6]
Internet-Draft Packet PW February 2009
Edge (PWE3) Architecture", RFC 3985, March 2005.
Authors' Addresses
Stewart Bryant (editor)
Cisco Systems
250, Longwater, Green Park,
Reading, Berks RG2 6GB
UK
Phone: UK
Fax:
Email: stbryant@cisco.com
URI:
Sami Boutros
Cisco Systems
3750 Cisco Way
San Jose, CA 95134
USA
Phone:
Fax:
Email: sboutros@cisco.com
URI:
Luca Martini
Cisco Systems
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
USA
Phone:
Fax:
Email: lmartini@cisco.com
URI:
Bryant, et al. Expires August 31, 2009 [Page 7]
Internet-Draft Packet PW February 2009
Siva Sivabalan
Cisco Systems
2000 Innovation Drive
Kanata, Ontario K2K 3EB
Canada
Phone:
Fax:
Email: msiva@cisco.com
URI:
George Swallow
Cisco Systems
1414 Massachusetts Ave
Boxborough, MA 01719
USA
Phone:
Fax:
Email: swallow@cisco.com
URI:
David Ward
Cisco Systems
3750 Cisco Way
San Jose, CA 95134
USA
Phone:
Fax:
Email: wardd@cisco.com
URI:
Andy Malis
Verizon Communications
117 West St.
Waltham, MA 02451
USA
Phone:
Fax:
Email: andrew.g.malis@verizon.com
URI:
Bryant, et al. Expires August 31, 2009 [Page 8]