Network Working Group Yong Lucy
Internet Draft Huawei
Intended status: Standard Track October 8, 2010
Expires: April 2011
Flow-Aware Pseudowire for the Virtual Private LAN Service
draft-yong-l2vpn-fat-pw-4-vpls-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.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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.
Yong Expires April 8, 2011 [Page 1]
Internet-Draft FAT-PW-4-VPLS October 2010
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 April 8, 2009.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
A pseudowire (PW) is used in Virtual Private LAN Service (VPLS)
solutions to form any-to-any connections and provide service
demuliplexing among Provider Edge routers (PEs), and is normally
transported over one single network path. Flow-aware PW enable a PW
to take advantage of Equal Cost Multipath (ECMP) and/or Link
Aggregation Groups (LAG) in a packet switched network (PSN). PW
packets with a flow label can be transported over multi-paths. This
method can apply to the PWs in a VPLS service.
This document describes how VPLS solutions utilize a PW with a flow
label, and defines protocol extension for the provisioning of such
PWs.
Table of Contents
1. Introduction...................................................3
2. Conventions Used in This Document..............................3
3. VPLS Supported by PW with a Flow Label.........................4
3.1. RFC4761 Extension for PW with a Flow Label................4
Yong Expires April 8, 2011 [Page 2]
Internet-Draft FAT-PW-4-VPLS October 2010
3.2. RFC4762 Extension for PW with Flow Label..................5
3.3. Virtual Service Instance (VSI) Forwarder..................6
3.4. Flow Identification.......................................6
4. Security Considerations........................................7
5. IANA Considerations............................................7
6. References.....................................................7
6.1. Normative References......................................7
6.2. Informative References....................................7
7. Acknowledgments................................................8
1. Introduction
[RFC4664] specifies the Layer 2 virtual private network (L2VPN)
framework. The L2VPN framework uses a point-to-point (P2P) pseudowire
(PW) between any pair of Provider Edge routers (PEs) to provide
connection and service demultiplexing. Each P2P PW is mapped to a
traffic engineered (TE) tunnel traversing a packet switched network
(PSN).
Two popular L2VPN services are Virtual Private Wire Service (VPWS)
and Virtual Private LAN Service (VPLS). VPWS is a P2P transport
service. VPLS is multi-point emulated LAN service. Two standard VPLS
solutions are specified in [RFC4761] and [RFC4762]. One is BGP-based
auto-discovery and singling; the other is LDP-based signaling.
Flow-aware PW [FAT-PW] is developed recently in IETF. It adds a flow
label on the label stack and enables the distinction of the flows
within a PW being carried over equal cost multipath (ECMP) and/or a
link aggregation group (LAG) in a packet switched network (PSN). The
target application of a PW with a flow label (i.e., of a PW split
across multiple parallel paths) is to transport large volumes of IP
traffic between two routers, for example, when providing a VPWS.
Service Providers use VPLS to provide an emulated LAN service and to
transport customer Layer 2 frames between Customer Edge routers
(CEs). Many L2VPN services carry Layer 2 frames that contain IP
payloads. There is an incentive for a service provider to use the PW
with a flow label in a VPLS service to support large volumes of data
between points on the emulated LAN. This document describes a VPLS
solution that uses a PW with a flow label and defines protocol
extension for provisioning the PW.
2. Conventions Used in This Document
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].
Yong Expires April 8, 2011 [Page 3]
Internet-Draft FAT-PW-4-VPLS October 2010
3. VPLS Supported by PW with a Flow Label
A VPLS is a layer 2 service that emulates an Ethernet LAN across a
Wide Area Network (WAN). It is a multipoint service. Although VPLS
service frames are Ethernet frames, and frame forwarding is based on
the destination MAC address, CE devices may be routers where the
frame payload is IP data.
[RFC4761] specifies BGP based auto-discovery and signaling for VPLS
configuration and operation procedures. [RFC4762] specifies LDP based
VPLS configuration and operation procedures. Both configure PWs to
support a VPLS instance, and in both cases the PW cannot be split
across multiple paths. The extensions in this document are necessary
for provisioning the PWs with a flow label that can be split across
multiple paths in a VPLS instance.
Note: a VPLS service that uses PW with a flow label may have some
different service aspects in a PSN from the one that does not. It is
outside the scope of this document how a service provider
differentiates the service profile between these two cases and how a
PE classifies the flows for a PW with a flow label.
3.1. RFC4761 Extension for PW with a Flow Label
[RFC4761] uses BGP to discover PEs in a VPLS instance and configure a
PW between any pair of PEs in the VPLS instance. [RFC4761] uses VPLS
BGP Network Layer Reachability Information (NLRI) to exchange VPLS
membership and demultiplexers, and uses the "Layer 2 Info Extended
Community" to signal control information about the PW to be setup for
a VPLS edge device (VE).
In this case, if a flow label is to be used to allow the PW to be
carried over ECMP or a LAG, it is necessary to coordinate the use of
the flow label between the ingress and egress PE. To signal the
presence of the flow label in a PW, this document suggests using two
bits in Control Flags. [RFC4761] has specified "Layer 2 Info Extended
Community" and Control Flags Bit Vector. This document suggests using
two bits in Control Flags Bit Vector to signal flow label present
between the ingress and egress PEs. The suggested format is shown
below.
Yong Expires April 8, 2011 [Page 4]
Internet-Draft FAT-PW-4-VPLS October 2010
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |T|R|C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Name C and S remain the same meaning as [RFC4761]. Name T and R are
defined here.
o When T=1 the PE is requesting the ability to send a PW packet that
includes a flow label. When T=0, the PE is indicating that it
will not send a PW packet containing a flow label.
o When R=1 the PE is able to receive a PW packet with a flow label
present. When R=0 the PE is unable to receive a PW packet with
the flow label present.
The two new bits in Control Flags are used to synchronize the flow
label state between the ingress and egress PEs. If PE does not
support flow label, these two bits MUST be set to zero according to
[RFC4761], which preserves backward compatibility. A PE that uses BGP
signaling and does not set T bit to 1 MUST NOT include a flow label
in the PW packet. This preserves backward compatibility with existing
PW specifications.
A PE sending a Control Flag with T = 1 to a peer PE and receiving a
Flow Label Flag with R = 1 from the peer PE SHOULD include a flow
label in the PW packet. Under all other combinations of Flow Label
Flag in signaling a PE MUST NOT include a flow label in the PW
packet.
The signaling process allows that some PWs in a VPLS instance use a
flow label on PW packets and other PWs in the same VPLS instance do
not use flow labels. This provides the flexibility to support network
migration.
What is signaled is the desire to include the flow label in the label
stack. As [FAT-PW] mentions, the value of the label is a local
matter for the ingress PE, and the label value itself is not
signaled.
3.2. RFC4762 Extension for PW with Flow Label
[RFC4762] uses LDP to provision a VPLS instance and configure an
Ethernet PW [RFC4448] between every pair of PEs to form a full mesh
topology among PEs.
Yong Expires April 8, 2011 [Page 5]
Internet-Draft FAT-PW-4-VPLS October 2010
[RFC4762] identified three relevant interface parameters for a VPLS.
This document adds the Flow Label Sub-TLV defined in [FAT-PW] as a
relevant interface parameter for a VPLS. When Flow Label Sub-TLV is
presented in label mapping message, ingress and egress PE MUST
perform the same procedures described in section 4 of [FAT-PW].
If LDP signaling [RFC4762] is not in use for PW setup, then whether
the flow label is used or not MUST be identically provisioned in both
PEs at the PW endpoints. If there is no provisioning support for
this option, the default behavior is not to include the flow label.
Data forwarding on an Ethernet PW MUST follow the procedures
described in [RFC4762].
3.3. Virtual Service Instance (VSI) Forwarder
Each VPLS forms a full mesh among PEs in the VPLS. Every VSI at a PE
in a given VPLS has exactly one point-to-point PW to every other VSI
in the same VPLS. MAC address learning is done per PW association,
i.e., the FIB keeps the mapping of the customer MAC address and PW
association.[RFC4664]
When a PW in a VPLS is used with a flow label, the PW still appears
as one single PW to the VSI. The VSI forwarder function is the same
as the PW without flow label.[RFC4762] It is worth mentioning the
case that, if ECMP is used at PEs, the ingress PE may distribute PW
packets with the flow label to different tunnels; so the egress PE
gets the packets from different tunnels and pass them to the same PW
forwarder. The distribution method is local and outside the scope of
document.
Flow recognition is discussed in Section 3.4. The VSI forwarder
SHOULD be able to generate a flow label and process PW encapsulation
as described in section 3.1 or 3.2.
It is possible that a VPLS uses point-to-multipoint (P2MP) PWs for
traffic optimization [P2MP-PW-REQ], [BCAST-EXT]. A P2MP PW with a
flow label requires that all the egress points can process that flow
label, which makes harder to synchronize the decision. The solution
for P2MP is for further study.
3.4. Flow Identification
A VPLS service transports customer Ethernet frames. When using a PW
with a flow label, it requires that ingress PE identifies a flow or a
group of flows within the service so that all frames from any one
flow are given the same flow label and treated the same way in the
Yong Expires April 8, 2011 [Page 6]
Internet-Draft FAT-PW-4-VPLS October 2010
network. This can be done by parsing the ingress Ethernet traffic and
considering all of the IP traffic. Source and destination IP address,
source and destination port, and protocol type may be used to
identify the flow. Whether the ingress PE uses a PE bridge element or
VSI forwarder to recognize the flow is a local implementation matter
and is outside the scope of document.
4. Security Considerations
The protocol extension in this draft does not introduce any new
security risk to the services and network beyond the analysis in
[FAT-PW].
5. IANA Considerations
Not Any.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS Networks",
RFC 4448, April 2006.
[RFC4761] Kompella, K., Rekhter, Y., "BGP Auto-Discovery and
Signaling for VPLS", RFC 4761, January 2007.
[RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling,
6.2. Informative References
[RFC4664] Andersson, L., Rosen, E.,"Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, 2006.
[FAT-PW] Bryan, S., et. Al, "Flow Aware Transport of Pseudowire over
an MPLS PSN", draft-ietf-pwe3-fat-pw-04, Work in progress.
[P2MP-PW-REQ] Jounay, F., et. al, "Requirements for Point to
Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-
03.txt, Work in progress.
Yong Expires April 8, 2011 [Page 7]
Internet-Draft FAT-PW-4-VPLS October 2010
[BCAST-EXT] Delord, S. et. Al, Extension to LDP-VPLS for Ethernet
Broadcast and Multicast, draft-delord-l2vpn-ldp-vpls-
broadcast-exten-03-txt, work in progress.
7. Acknowledgments
Author would like to thank Adrian Farrel, Mach Chen for the review
and valuable suggestions.
Yong Expires April 8, 2011 [Page 8]
Internet-Draft FAT-PW-4-VPLS October 2010
Authors' Addresses
Lucy Yong
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 469-229-5387
Email: lucyyong@huawei.com
Yong Expires April 8, 2011 [Page 9]