Internet DRAFT - draft-li-spring-segment-path-programming
draft-li-spring-segment-path-programming
Network Working Group Z. Li
Internet-Draft I. Milojevic
Intended status: Informational Z. Zhuang
Expires: April 19, 2016 Huawei Technologies
October 17, 2015
Segment Path Programming (SPP)
draft-li-spring-segment-path-programming-00
Abstract
Segment Routing for unicast traffic has been proposed to cope with
the usecases in traffic engineering, fast re-reroute, service chain,
etc. The document generalizes more use cases based on segment and
proposes the concept of Segment Path Programming. In the field of
Segment Path Programming: 1. The Segment used in the programmed
segment path is not only used in the forwarding plane, but also used
in the control plane. 2. The programmed segment path is not only
used in the transport layer, but also used in the service layer.
Accordingly this document proposes use cases, architecture and
protocol extension requirements for the Segment Path Programming
(SPP).
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 April 19, 2016.
Li, et al. Expires April 19, 2016 [Page 1]
Internet-Draft Segment Path Programming (SPP) October 2015
Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Redefinition of Segment . . . . . . . . . . . . . . . . . . . 3
3.1. Application of Segment in Control Plane and Forwarding
Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Application of Segment in Reachability and Service
Process . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definition of Segment Path Programming Path . . . . . . . . . 6
5. Usecases of Segment Path Programming . . . . . . . . . . . . 7
5.1. Flexible Service Process Combination . . . . . . . . . . 7
5.2. Node Segment for Synonymous Flow Label . . . . . . . . . 8
5.3. Steering Traffic without Mapping Segment to Label . . . . 8
5.4. Centralized Mapping Service to Tunnels . . . . . . . . . 9
6. Framework of Service-Oriented MPLS Path Programming . . . . . 11
6.1. Central Control for MPLS Path Programming . . . . . . . . 11
6.2. Protocol Extensions Requirements . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Segment Routing [I-D.ietf-spring-segment-routing] for unicast traffic
has been proposed to cope with the usecases in traffic engineering,
fast re-reroute, service chain, etc. The document generalizes more
use cases based on segment and proposes the concept of Segment Path
Programming. In the field of Segment Path Programming: 1. The
Segment used in the programmed segment path is not only used in the
Li, et al. Expires April 19, 2016 [Page 2]
Internet-Draft Segment Path Programming (SPP) October 2015
forwarding plane, but also used in the control plane. 2. The
programmed segment path is not only used in the transport layer, but
also used in the service layer. Accordingly this document proposes
use cases, architecture and protocol extension requirements for the
Segment Path Programming (SPP).
2. Terminology
BGP: Border Gateway Protocol
L2VPN: Layer 2 VPN
L3VPN: Layer 3 VPN
SPP: Segment Path Programming
SR-path: Segment Routing Path
SRGB: SR Global Block
3. Redefinition of Segment
3.1. Application of Segment in Control Plane and Forwarding Plane
In the existing segment routing, the segment will be applied to the
MPLS forwarding plane directly. In the MPLS architecture, the global
segment such as node segment will be mapped to MPLS label since SRGB
will be defined as the set of local labels reserved for global
segments and the local segment will be a local label outside the
SRGB.
In fact, the segment can be only used in the control plane instead of
mapping to the forwarding plane. In the usecase, the segment is just
an indicator for specific process which can be used for the
application of Segment Path Programming.
For example, node segment in the Segment Routing mapped in the
control plane and forwarding plane in the MPLS architecture is shown
in the following figure.
Li, et al. Expires April 19, 2016 [Page 3]
Internet-Draft Segment Path Programming (SPP) October 2015
Control Plane:
+---------+ +------------+
| Segment | | |
| | = | Label |
| ID | | |
+---------+ +------------+
Forwarding Plane:
+--------+------------+ +------------+-------------------------+
| | Forwarding | | Forwarding | Forwarding Information |
| Label | | --> | | to |
| | Index | | Index | Specified Node |
+--------+------------+ +------------+-------------------------+
Figure 1: Node Segment in Segment Routing
In the Segment Path Programming, the node segment can be enhanced to
support following mapping in the control plane and forwarding plane
even in the MPLS architecture.
Control Plane:
+---------+ +------------+
| Segment | | Forwarding |
| | --> | |
| ID | | Index |
+---------+ +------------+
Forwarding Plane:
+------------+-------------------------+
| Forwarding | Forwarding Information |
| | to |
| Index | Specified Node |
+------------+-------------------------+
Figure 2: Enhanced Node Segment in Segment Path Programming
In this mapping, the Segment ID can map to the forwarding entry to
specific node. But it is only an indicator in the control plane
which can be used for possible applications. When receive the
mapping information between the application and the Segment ID, the
network node will install additional forwarding entry as follows
which map the application information to the forwarding information
specified by the segment ID.
Li, et al. Expires April 19, 2016 [Page 4]
Internet-Draft Segment Path Programming (SPP) October 2015
Control Plane:
Mapping Information
+--------+------------+
| App | Segment |
| | |
| Info | ID |
+--------+------------+
Forwarding Plane:
+----------+------------+ +------------+-------------------------+
| | Forwarding | | Forwarding | Forwarding Information |
| App Info | | --> | | to |
| | Index | | Index | Specified Node |
+----------+------------+ +------------+-------------------------+
Figure 3: Mapping App to Segment in Segment Path Programming
The application information in the forwarding entry should be derived
from the packet received by the network nodes such as the destination
IP/MAC address, the source IP/MAC address, the port number, the
protocol number, etc. It can also be the MPLS label.
In order to support the enhanced segment in the Segment Programming
Path, whether to map the Segment to MPLS label can be determined by
the local policy of the network node. Protocol extensions can also
be introduced to specify if the Segment maps to the MPLS label when
advertised the information of SRGBs or all kinds of Segments.
3.2. Application of Segment in Reachability and Service Process
In the existing Segment Routing, in the MPLS architecture the segment
will be mapped to the label which is always the indicator of
reachability to the specific node, the specific agency, etc. More
types of Segments which indicates the reachability can be introduced
according to existing MPLS forwarding plane. Since these segments
represent reachability in the network, they can be used for traffic
steering. These segments includes:
-- Node Segment
-- Agency Segment
-- AS (Autonomous System) Segment
-- Anycast Segment
-- Multicast Segment
Li, et al. Expires April 19, 2016 [Page 5]
Internet-Draft Segment Path Programming (SPP) October 2015
-- Tunnel Segment
-- VPN Segment
-- etc.
As the development of Segment Routing, the service segment is
introduced to represent the specific service process. It can be used
for some new application scenarios such qw the Service Function Chain
(SFC). For the service process in the traditional IP/MPLS fowarding
plane, it can also be indicated by different types of segments. This
provides the possibility to flexibly combine these segment to set up
a Segment Path to represent a series of service process in the
network on the specific flow instead of only steering traffic. These
Segments can represent different service process in the forwarding
plane as follows:
-- OAM Segment
-- ECMP (Equal Cost Multi-Path) Segment
-- QoS Segment
-- Bandwidth-Guarantee Segment
-- Security Segment
-- Multi-Topology Segment
-- etc.
4. Definition of Segment Path Programming Path
Owing to more types of segments and flexible application of segment
in the control plane and the forwarding plane, there will be powerful
capability to combine these segments which can be used to steering
traffic or provide flexible service process to satisfy different
service requirement for specific flows in the network. We call such
combination of segments as Segment Path and the flexible combining of
segments as Segment Path Programming.
Segment Routing ([I-D.ietf-spring-segment-routing]) is a typical
example of Segment Path Programming. There can be multiple layers
for Segment Path Programming which are shown in the following figure:
Li, et al. Expires April 19, 2016 [Page 6]
Internet-Draft Segment Path Programming (SPP) October 2015
+---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE|
+--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+
Service-oriented Segment Path Programming
(SoSPP)
o--------o--------- Service Layer------------o--------o
o--------- Network Layer -----------o
Transport-oriented Segment Path Programming
(Segment Routing)
o-------o--------o---------o-------o Transport Layer
o-----o o-----o o-----o o-----o o-----o o-----o Link Layer
Figure 4: Multiple Layers of Segment Path Programming
Now the segment routing is to provide the source packet routing in
the transport layer or the link layer for traffic steering . We can
call such type of source packet routing as Transport-Oriented Segment
Path Programming. There can be more application scenarios which need
the segment path to respresent the service processes in the service
layer or network layer. We call these types of source packet routing
as Service-Oriented Segment Path Programming.
5. Usecases of Segment Path Programming
5.1. Flexible Service Process Combination
The following figure shows the usecase of Segment Path Programming to
combine service segments according to the service requirements on the
traffic which can be specified by the traditional BGP VPN prefix.
The combination of these service segments represent the required
ECMP, QoS and OAM process.
Li, et al. Expires April 19, 2016 [Page 7]
Internet-Draft Segment Path Programming (SPP) October 2015
Traditional Label Binding for VPN Prefix:
+----------+----------+
| VPN |VPN Prefix|
| Prefix | Label |
+----------+----------+
Additional Segment Path Information:
+----------+----------+----------+
| ECMP | QoS | OAM |
| Segment | Segment | Segment |
+----------+----------+----------+
If the network node maps the corresponding segment to MPLS label, the
forwarding entry can be as follows:
+----------+ +----------+----------+----------+----------+
|VPN Prefix| | Entropy | QoS | OAM |VPN Prefix| Transport Tunnel
| | --> | Label | Label | Label | Label | ---> determined by
+----------+ +----------+----------+----------+----------+ BGP Nexthop
5.2. Node Segment for Synonymous Flow Label
Synonymous flow label has been proposed by
[I-D.bryant-mpls-synonymous-flow-labels] to solve the issue of the
measurement of packet loss for multipoint-to-point LSP. Node segment
advertised in the Segment Routing can be used as the flow label. In
the scenario of performance measurement the flow label can only be
interpreted by network node to identify the source of the flow other
than set up the MPLS forwarding entry for the node segment in the
scenario of segment routing. So when advertise the node segment
information on the usage of the node segment can also be carried or
the local policy can be introduced to determine the application of
the node segment. Then the segment path can be set up based on such
node segment for the purpose of performance measurement.
5.3. Steering Traffic without Mapping Segment to Label
The following figure shows the usecase of Segment Path Programming to
steer traffic which can be specified by the traditional BGP prefix.
Li, et al. Expires April 19, 2016 [Page 8]
Internet-Draft Segment Path Programming (SPP) October 2015
Traditional BGP Prefix:
+----------+
| BGP |
| Prefix |
+----------+
Additional Segment Path Information:
+----------+----------+
| Agency | Node |
| Segment | Segment |
+----------+----------+
If these segments are not applied in the MPLS forwarding plane, the
Segment Path will be explained as steering traffic specified by the
BGP prefix to reach specific node (determined by the Node Segment)
through specific local link (determined by the Agency Segment). The
corresponding fowarding entry will be as follows:
+----------+------------+ +------------+---------------+--------------------+
| BGP | Forwarding | | Forwarding | Next Hop | Outgoing Interface |
| | | --> | | determined by | determine by |
| Prefix | Index | | Index | Node Segment | Link Segment |
+----------+------------+ +------------+---------------+--------------------+
5.4. Centralized Mapping Service to Tunnels
In the transport layers, there can be multiple tunnels with different
constraints to one specific destination. In the traditional way, the
tunnel is set up by the distributed forwarding nodes. As the PCE-
initiated LSP setup [I-D.ietf-pce-pce-initiated-lsp]is introduced,
the tunnel setup can be triggered by the central controlled way. In
order to satisfy the different service requirements, it is necessary
to provide the capability to flexibly map the service to different
tunnels. Since the central control point has enough information
based on the whole network view, it can be an effective way to map
the service to the tunnel by the central point and advertise the
mapping information to the end-points of the service to guide the
mapping in the forwarding node.
The method to implement mapping service to tunnels can directly
introduce the tunnel attribute to specify the tunnel proposed by
[I-D.li-idr-mpls-path-programming]. [I-D.li-spring-tunnel-segment]
proposes one new type of segment, Tunnel Segment, which can provide
an alternative way to implement mapping service to tunnels. In the
following figure, the central controller can trigger to set up the
MPLS TE tunnels through PCE-initiated LSP and allocate Segment ID for
the tunnel in the Node-1.
Li, et al. Expires April 19, 2016 [Page 9]
Internet-Draft Segment Path Programming (SPP) October 2015
+------------+
| Central |
| Controller |
+------------+
^ Tunnel Binding
| SID (Z)
| .-----.
| ( )
V .--( )--.
+-------+ ( ) +-------+
| |_( IP/MPLS Network )_| |
|Node-1 | ( ================> ) |Node-2 |
+-------+ (MPLS TE/IP Tunnel) +-------+
'--( )--'
( )
'-----'
Figure 5: Using Tunnel Segment for Mapping Service to Tunnel
Without applying the segment to MPLS label the Node-1 can set up the
following mapping for the tunnel segment:
Control Plane:
+---------+ +------------+
| Segment | | Forwarding |
| | --> | |
| ID | | Index |
+---------+ +------------+
Forwarding Plane:
+------------+-----------------------+
| Forwarding | Tunnel Forwarding |
| | |
| Index | Information |
+------------+-----------------------+
Figure 6: Enhanced Node Segment in Segment Path Programming
Then the central controller can advertise following Segment Path
information for the flow which can be specified by the traditional
BGP prefix.
Li, et al. Expires April 19, 2016 [Page 10]
Internet-Draft Segment Path Programming (SPP) October 2015
Traditional BGP Prefix:
+----------+
| BGP |
| Prefix |
+----------+
Additional Segment Path Information:
+----------+
| Tunnel |
| Segment |
+----------+
Then the following forwarding entry can be set up for the specified
BGP prefix to steer traffic to specific tunnel in the Noed-1.
+----------+------------+ +------------+----------------------+
| BGP | Forwarding | | Forwarding | Tunnel Forwarding |
| | | --> | | |
| Prefix | Index | | Index | Information |
+----------+------------+ +------------+----------------------+
6. Framework of Service-Oriented MPLS Path Programming
6.1. Central Control for MPLS Path Programming
Central control plays an important role in Segment Path Programming
shown in the figure 7. There are two important functionalities for
the central controller:
1. Central controlled Segment allocation/collection: Segment can be
allocated centrally for specific usage. Or central controller can
collect the segment binding information from the network nodes.
BGP/PCEP/IGP extensions can be introduced to distribute or collect
the segment binding information.
2. Central controlled Segment Path Programming: Central controller
can calculate path in a global network view and implement the Segment
Path Programming based on the collected information of segments to
satisfy different requirements of service flows. BGP/PCEP extensions
can be introduced to download the Segment Path for the Service/
Network layer or Transport/Link layer.
Li, et al. Expires April 19, 2016 [Page 11]
Internet-Draft Segment Path Programming (SPP) October 2015
+-------------------+
| Central |
| Controller |
|----------|(Path Calculation |--------|
| | /Path Programming)| |
| +-------------------+ |
| / | \ |
Segment Path / Segment \ Segment Path
| / | \ |
| Segment | Segment |
| / | \ |
| / | \ |
| / | \ |
+--------+ +--------+ +--------+
| CLIENT | | CLIENT | | CLIENT |
| | ...... | | ...... | |
| (PE) | | (P) | | (PE) |
| | | | | |
+--------+ +--------+ +--------+
Figure 7: Central Control for Segment Path Programming
6.2. Protocol Extensions Requirements
REQ 01: BGP/PCEP/IGP extensions should be introduced to distribute
Segment binding for specific usage from the central controller to
other client nodes.
REQ 02: BGP/PCEP/IGP extensions should be introduced to collect
Segment binding for specific usage from the client nodes to the
central controller.
REQ 03: BGP extensions should be introduced to download Segment
(stack) for Segment Path of the service/network layer.
REQ 04: PCE extensions should be introduced to download Segment
(stack) for Segment Path of the transport layer.
REQ 05: Protocol extensions should be introduced to specify the
application of SRGB or Segment which means if the segment is applied
to MPLS forwarding plane.
7. IANA Considerations
This document makes no request of IANA.
Li, et al. Expires April 19, 2016 [Page 12]
Internet-Draft Segment Path Programming (SPP) October 2015
8. Security Considerations
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>.
9.2. Informative References
[I-D.bryant-mpls-synonymous-flow-labels]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen,
M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft-
bryant-mpls-synonymous-flow-labels-01 (work in progress),
July 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-04 (work in
progress), April 2015.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and r. rjs@rob.sh, "Segment Routing Architecture", draft-
ietf-spring-segment-routing-06 (work in progress), October
2015.
[I-D.li-idr-mpls-path-programming]
Li, Z., "BGP Extensions for Service-Oriented MPLS Path
Programming (MPP)", draft-li-idr-mpls-path-programming-01
(work in progress), March 2015.
[I-D.li-spring-tunnel-segment]
Li, Z. and N. Wu, "Tunnel Segment in Segment Routing",
draft-li-spring-tunnel-segment-00 (work in progress),
September 2015.
Authors' Addresses
Li, et al. Expires April 19, 2016 [Page 13]
Internet-Draft Segment Path Programming (SPP) October 2015
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Igor Milojevic
Huawei Technologies
Poland-Warsaw-TULIPAN HOUSE, UL. DOMANI EWSKA 50, 02-672
Warsaw
Poland
Email: Igor.Milojevic@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Li, et al. Expires April 19, 2016 [Page 14]
