Network Working Group Z. Li
Internet-Draft X. Chen
Intended status: Standards Track S. Zhuang
Expires: August 31, 2016 Huawei Technologies
February 28, 2016
PCEP Extension for Flow Specification
draft-li-pce-pcep-flowspec-00
Abstract
Dissemination of the traffic flow specifications was first introduced
in the BGP protocol via RFC 5575. In order to distribute the flow
specifications from PCE controller to network device without BGP
protocol it is desirable to extend PCEP with flow specification
information.
This document specifies a set of extensions to PCEP to support
dissemination of flow specifications. The extensions include the
instantiation, updation and deletion of flow specifications.
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 RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 31, 2016.
Li, et al. Expires August 31, 2016 [Page 1]
Internet-Draft PCEP-FlowSpec February 2016
Copyright Notice
Copyright (c) 2016 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Procedures for Dissemination of FlowSpec . . . . . . . . . . 4
3.1. Overview of Procedures . . . . . . . . . . . . . . . . . 4
3.2. Capability Advertisement . . . . . . . . . . . . . . . . 5
3.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 5
4. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. PCEP FlowSpec Message . . . . . . . . . . . . . . . . . . 6
5. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 7
5.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. PCE FlowSpec Capability TLV . . . . . . . . . . . . . 8
5.2. FLOW Object . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. ACTION Object . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 13
Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Dissemination of the traffic flow specifications was first introduced
in the BGP protocol [RFC5575]. The traffic flow specification is
comprised of traffic filtering rules and actions. The routers which
received the flow specification can take advantage of the ACL (Access
Control List) or firewall capabilities in the router's forwarding
path. The routers can classify the packets according to the traffic
Li, et al. Expires August 31, 2016 [Page 2]
Internet-Draft PCEP-FlowSpec February 2016
filtering rules and shape, rate limit, filter, or redirect packets
based on the actions. The flow specification carried by BGP can be
used to automate inter-domain coordination of traffic filtering to
mitigate (distributed) denial-of-service attacks and can also be used
to provide traffic filtering in the context of a BGP/MPLS VPN
service.
[RFC5575] also defines that a flow specification received from an
external autonomous system will need to be validated against unicast
routing before being accepted. [I-D.ietf-idr-bgp-flowspec-oid]
describes a modification to the validation procedure defined in
[I-D.ietf-idr-bgp-flowspec-oid] for the dissemination of BGP flow
specifications. The modification proposed enables flow
specifications to be originated from a centralized BGP route
controller.
[I-D.ietf-ospf-flowspec-extensions] defines the extensions to OSPF to
distribute flow specifications in the networks that only deploy an
IGP (Interior Gateway Protocol) (e.g., OSPF). It also defines the
validation procedures for imposing the filtering information on the
routers.
[RFC5440] describes the Path Computation Element Protocol (PCEP).
PCEP defines the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between PCE and PCE,
enabling computation of Multiprotocol Label Switching (MPLS) for
Traffic Engineering Label Switched Path (TE LSP) characteristics.
Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of
extensions to PCEP to enable stateful control of TE LSPs between and
across PCEP sessions in compliance with [RFC4657]. It includes
mechanisms to effect LSP state synchronization between PCCs and PCEs,
delegation of control of LSPs to PCEs, and PCE control of timing and
sequence of path computations within and across PCEP sessions and
focuses on a model where LSPs are configured on the PCC and control
over them is delegated to the PCE. [I-D.ietf-pce-pce-initiated-lsp]
describes the setup, maintenance and teardown of PCE- initiated LSPs
under the stateful PCE model, without the need for local
configuration on the PCC, thus allowing for a dynamic network that is
centrally controlled and deployed.
In case PCE is used to initiate tunnels via PCEP, it is desirable to
use the same protocol to also distribute the flow specifications to
describe what data flows on those tunnels. Thus, in order to
distribute the flow specifications from PCE controller to network
device, PCEP is extended with flow specification information in this
document.
Li, et al. Expires August 31, 2016 [Page 3]
Internet-Draft PCEP-FlowSpec February 2016
This document specifies a set of extensions to PCEP to support
dissemination of flow specifications. The flow specifications can be
disseminated between PCEP peers such as from PCE to PCC or between
PCEs . The extensions include the creation, updation and withdrawal
of flow specifications via PCEP.
The values of flow filtering rules and actions mainly refer to the
BGP flow specification and IGP specification. This document extends
new actions which are redirecting to LSP (refered by Symbolic Path
Name, IPv4 LSP, or IPv6 LSP).
2. Terminology
This document uses the terms defined in [RFC5440] and [RFC5575].
This document uses the terms defined in [RFC5440]: PCC, PCE, PCEP
Peer.
The following term is from [RFC5575]. It is used frequently
throughout this document:
Flow Specification (FlowSpec): A flow specification is an n-tuple
consisting of several matching criteria that can be applied to IP
traffic, including filters and actions. Each FlowSpec consists of a
set of filters and a set of actions.
3. Procedures for Dissemination of FlowSpec
3.1. Overview of Procedures
A PCC or PCE indicates its ability to support PCE FlowSpec during the
PCEP Initialization Phase via "PCE FlowSpec Capability" TLV (see
details in Section 5.1.1).
This section introduces the procedure to support PCE FlowSpec as
follows:
Firstly both the PCE and PCC advertise the PCE FlowSpec Capability
during the PCE session initiation phase.
On the PCEP session with PCE FlowSpec Capability PCE communicates
with PCC to create, update and withdraw PCE FlowSpec.
[Editor's Note - The procedure about PCE FlowSpec synchronization,
the session failure process, etc. will be specified in the future
version.]
Li, et al. Expires August 31, 2016 [Page 4]
Internet-Draft PCEP-FlowSpec February 2016
3.2. Capability Advertisement
During PCEP session establishment, both the PCC and the PCE must
announce their support of PCEP extensions for FlowSpec defined in
this document.
A PCEP Speaker (PCE or PCC) includes the "PCE FlowSpec Capability"
TLV, described in Section 5.1.1, in the OPEN Object to advertise its
support for PCEP extensions for PCE FlowSpec Capability.
The presence of the PCE FlowSpec Capability TLV in PCE's OPEN message
indicates that the PCE can support distribute the FlowSpec to PCC.
The presence of such Capability TLV in PCC's OPEN Object indicates
that the PCC can be in support of Flowspec functionality to
instantiate the FlowSpec according to the PCE's indication and can
apply the FlowSpec to the incoming packets.
If PCE has such capability TLV and PCC has no such capability TLV PCE
MUST NOT send the PCE messages with FlowSpec information. And if PCC
receives such messages it should send PCErr message to PCE.
[Editor's Note - PCE discovery via IGP should also be extended for
this.]
3.3. Operations
To instantiate a FlowSpec which is comprised of a set of FlowSpec
filter rules and actions, the PCE sends a new PCEP message (called
FlowSpec message) to the PCC. The FlowSpec message MUST include the
SRP object[I-D.ietf-pce-stateful-pce], a new FLOW object (see details
in Section 5.2) and a new ACTION object (see details in Section 5.3).
FLOW object carries a set of FlowSpec filter rules. A list of ACTION
objects specify a set of FlowSpec actions.
To update the FlowSpec actions of a specified FlowSpec which has been
created, the same PCEP message "FlowSpec" is used. The PCE sends a
FlowSpec message to the PCC. The FlowSpec message MUST include the
SRP object, FLOW object and ACTION object.
To delete the specified FlowSpec which has been created, the PCE
sends a FlowSpec message to the PCC with a flag indicating the
removal action. The FlowSpec message MUST include the SRP object
(with R flag set) and FLOW object.
Li, et al. Expires August 31, 2016 [Page 5]
Internet-Draft PCEP-FlowSpec February 2016
4. PCEP Messages
As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable-length body made of a set of objects that can
be either mandatory or optional. An object is said to be mandatory
in a PCEP message when the object must be included for the message to
be considered valid. For each PCEP message type, a set of rules is
defined that specify the set of objects that the message can carry.
An implementation MUST form the PCEP messages using the object
ordering specified in this document.
To support the PCEP FlowSpec functionality one new PCEP messages is
introduced.
4.1. PCEP FlowSpec Message
A FlowSpec message which is also referred to as FlowSpec message is a
PCEP message sent by a PCE to a PCC to trigger creation, modification
or deletion of a FlowSpec.
The Message-Type field of the PCEP common header for the FlowSpec
message is to be assigned by IANA. The FlowSpec message MUST include
the SRP and the FLOW objects.
If FlowSpec message is used to create or update the FlowSpec, it MUST
include the ACTION objects too.
If FlowSpec message is used to delete the FlowSpec the ACTION objects
SHOULD NOT be carried and the SRP object is set with the R flag.
A FlowSpec is identified by a PCEP specific identifier FS-ID.
The format of a FlowSpec message for creation or deletion of FlowSpec
is as follows:
Li, et al. Expires August 31, 2016 [Page 6]
Internet-Draft PCEP-FlowSpec February 2016
<FlowSpec Message> ::= <Common Header>
<flowspec-list>
Where:
<flowspec-list> ::= <flowspec-request>[<flowspec-list>]
<flowspec-request>::= (<flowspec-create-or-update>|
<flowspec-delete>)
<flowspec-create-or-update> ::= <SRP>
<FLOW>
<action-list>
<flowspec-delete> ::= <SRP>
<FLOW>
Where:
<action-list>::=<ACTION>[<action-list>]
The SRP object defined in [I-D.ietf-pce-stateful-pce] can be used in
this document to correlate FlowSpec requests sent by the PCE with the
error reports sent by the PCC.
Every FlowSpec requests from the PCE sends a new SRP-ID-NUMBER as
described in [I-D.ietf-pce-stateful-pce]. This number is unique per
PCEP session and is incremented each time an FlowSpec operation
(creation, update, deletion etc) is requested from the PCE. The
value of the SRP-ID-NUMBER MAY be echoed back by the PCC in PCErr
messages to allow for correlation between requests made by the PCE
and errors generated by the PCC. Procedure of dissemination of
FlowSpec from PCE share the same number space of the SRP-ID-NUMBER
with procedure of stateful PCE.
The FLOW and ACTION objects are new objects introduced in this
document.
5. Objects and TLVs
The PCEP objects defined in this document are compliant with the PCEP
object format defined in [RFC5440].
New TLVs about FlowSpec filtering rules are defined. The value
portion of the new TLVs can reuse the structure defined in [RFC5575]
and [I-D.ietf-idr-flow-spec-v6]. New TLVs about FlowSpec actions are
also defined. The value portion of the new TLVs can reuse the
structure defined in [I-D.ietf-ospf-flowspec-extensions]. This
document also defines two new actions: Redirect to IPv4 LSP and
Redirect to IPv6 LSP.
Li, et al. Expires August 31, 2016 [Page 7]
Internet-Draft PCEP-FlowSpec February 2016
5.1. OPEN Object
5.1.1. PCE FlowSpec Capability TLV
The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV associated with
the OPEN Object [RFC5440] to exchange PCE FlowSpec capability of PCEP
speakers.
Its format is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value=0 |
+---------------------------------------------------------------+
Figure 1: PCE-FLOWSPEC-CAPABILITY TLV format
The type of the TLV is to be assigned by IANA and it has a fixed
length of 2 octets. The value field is set to default value 0.
The inclusion of this TLV in an OPEN object indicate that the sender
can perform FlowSpec handling in PCEP.
5.2. FLOW Object
The FLOW object MUST be present within FlowSpec messages. The FLOW
object carries a set of FlowSpec filter rules.
FLOW Object-Class is to be assigned by IANA.
Two FLOW Object-Type are defined so far:
o IPv4 FLOW: FLOW Object-Type is 1.
o IPv6 FLOW: FLOW Object-Type is 2.
The format of the FLOW object is as follows:
Li, et al. Expires August 31, 2016 [Page 8]
Internet-Draft PCEP-FlowSpec February 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FS-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Flow Filter TLVs(variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FLOW Object Body Format
FS-ID(32-bit): A PCEP-specific identifier for the FlowSpec
information. A PCE creates an unique FS-ID for each FlowSpec that is
constant for the lifetime of a PCEP session. All subsequent PCEP
messages then address the FlowSpec by the FS-ID. The values of 0 and
0xFFFFFFFF are reserved.
Flow Filter TLVs(variable): The FLOW object body has a variable
length and may contain one or more additional TLVs.
The following flow filter types are supported:
Li, et al. Expires August 31, 2016 [Page 9]
Internet-Draft PCEP-FlowSpec February 2016
+------+------------------------+-------+--------------------------+
| Type | Description |Ref TLV|Value defined in |
+------+------------------------+-------+--------------------------+
| TBD1 | Destination IPv4 Prefix| 1 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD2 | Source IPv4 Prefix | 2 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD3 | IP Protocol | 3 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD4 | Port | 4 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD5 | Destination port | 5 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD6 | Source port | 6 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD7 | ICMP type | 7 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD8 | ICMP code | 8 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD9 | TCP flags | 9 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD10| Packet length | 10 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD11| DSCP | 11 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD12| Fragment | 12 |RFC5575 |
+------+------------------------+-------+--------------------------+
| TBD13| Flow Label | 13 |I-D.ietf-idr-flow-spec-v6 |
+------+------------------------+-------+--------------------------+
| TBD14| Destination IPv6 Prefix| 1 |I-D.ietf-idr-flow-spec-v6 |
+------+------------------------+-------+--------------------------+
| TBD15| Source IPv6 Prefix | 2 |I-D.ietf-idr-flow-spec-v6 |
+------+------------------------+-------+--------------------------+
| TBD16| Next Header | 3 |I-D.ietf-idr-flow-spec-v6 |
+------+------------------------+-------+--------------------------+
Table 2: Flow Filter Types
5.3. ACTION Object
The ACTION object MUST be present within FlowSpec messages when
creating or updating the FlowSpec. The ACTION object carries a set
of FlowSpec actions.
ACTION Object-Class is to be assigned by IANA.
ACTION Object-Type is 1.
Li, et al. Expires August 31, 2016 [Page 10]
Internet-Draft PCEP-FlowSpec February 2016
The format of the ACTION object body is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ACTION TLVs(variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ACTION Object Body Format
The ACTION object body has a variable length and may contain one or
more additional TLVs.
The following FlowSpec action types are supported:
+------+---------------------+-------+-------------------------+
| Type | Description |Ref TLV|Value defined in |
+------+---------------------+-------+-------------------------+
| TBD17| traffic-rate | TBD |I-D.ietf-ospf-flowspec |
| | | |-extensions |
+------+---------------------+-------+-------------------------+
| TBD18| traffic-action | TBD |I-D.ietf-ospf-flowspec |
| | | |-extensions |
+------+---------------------+-------+-------------------------+
| TBD19| traffic-marking | TBD |I-D.ietf-ospf-flowspec |
| | | |-extensions |
+------+---------------------+-------+-------------------------+
| TBD20| redirect-to-IPv4 | TBD |I-D.ietf-ospf-flowspec |
| | | |-extensions |
+------+---------------------+-------+-------------------------+
| TBD21| redirect-to-IPv6 | TBD |I-D.ietf-ospf-flowspec |
| | | |-extensions |
+------+---------------------+-------+-------------------------+
| 18(*)| IPV4-LSP-IDENTIFIERS| - |I-D.ietf-pce-stateful-pce|
+------+---------------------+-------+-------------------------+
| 19(*)| IPV6-LSP-IDENTIFIERS| - |I-D.ietf-pce-stateful-pce|
+------+---------------------+-------+-------------------------+
| 17(*)| Symbolic-Path-Name | - |I-D.ietf-pce-stateful-pce|
+------+---------------------+-------+-------------------------+
Table 3: Flow Action Types
(*) The type is defined in [I-D.ietf-pce-stateful-pce]
Li, et al. Expires August 31, 2016 [Page 11]
Internet-Draft PCEP-FlowSpec February 2016
6. IANA Considerations
TBD.
7. Security Considerations
TBD.
8. Acknowledgements
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>.
[I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-13 (work in progress), December 2015.
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-05 (work in
progress), October 2015.
9.2. Informative References
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <http://www.rfc-editor.org/info/rfc4657>.
Li, et al. Expires August 31, 2016 [Page 12]
Internet-Draft PCEP-FlowSpec February 2016
[I-D.ietf-idr-bgp-flowspec-oid]
Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P.
Mohapatra, "Revised Validation Procedure for BGP Flow
Specifications", draft-ietf-idr-bgp-flowspec-oid-02 (work
in progress), January 2014.
[I-D.ietf-idr-flow-spec-v6]
Raszuk, R., Pithawala, B., McPherson, D., and A. Andy,
"Dissemination of Flow Specification Rules for IPv6",
draft-ietf-idr-flow-spec-v6-06 (work in progress),
November 2014.
[I-D.ietf-ospf-flowspec-extensions]
Liang, Q., You, J., Wu, N., Fan, P., Patel, K., and A.
Lindem, "OSPF Extensions for Flow Specification", draft-
ietf-ospf-flowspec-extensions-00 (work in progress), June
2015.
Appendix A. Contributor Addresses
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Shankara
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: shankara@huawei.com
Appendix B. Example Usage
Once PCE initiate tunnels, it needs to further decide what data needs
to flow on the newly created tunnel, a flow specification can be
created at the ingress to redirect the flow to the LSP as shown
below.
Li, et al. Expires August 31, 2016 [Page 13]
Internet-Draft PCEP-FlowSpec February 2016
*****
*PCE*
/*****
/
/
/
/
/
/ 1. PCInitiate
/ Message to
/ initiate LSP
/ (RTA-RTD)
/
/
/
V
+----+ +----+ +----+ +----+
|RTA |----------|RTB |----------|RTC |----------|RTD |
| | | | | | | |
+----+ +----+ +----+ +----+
PCC
Ingress
*****
*PCE*
/*****
/
/
/
/
/
/ 2. FlowSpec
/ Message to add flow
/ (source - x.x.x.x, port - y)
/ to redirect to LSP
/ (RTA-RTD)
/
/
V
+----+ +----+ +----+ +----+
|RTA |----------|RTB |----------|RTC |----------|RTD |
| | | | | | | |
+----+ +----+ +----+ +----+
PCC
Ingress
Li, et al. Expires August 31, 2016 [Page 14]
Internet-Draft PCEP-FlowSpec February 2016
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Xia Chen
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: jescia.chenxia@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Li, et al. Expires August 31, 2016 [Page 15]