Internet DRAFT - draft-dw-pce-service-segment-routing
draft-dw-pce-service-segment-routing
PCE Working Group D. Dhody
Internet-Draft Q. Wu
Intended status: Standards Track Huawei
Expires: September 7, 2015 March 6, 2015
PCEP Extensions for service segment used in Segment Routing
draft-dw-pce-service-segment-routing-01
Abstract
Segment Routing (SR) technology leverages the source routing and
tunneling paradigms where a source node can choose a path without
relying on hop-by-hop signaling.
This document specifies extensions to the Path Computation Element
Protocol (PCEP) that allow a stateful PCE to compute and instantiate
SR-TE paths that also have a local service segments involved.
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 September 7, 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
Dhody & Wu Expires September 7, 2015 [Page 1]
Internet-Draft Service Segment Routing March 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of PCEP Operation in SR Networks for Service
Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. The SR-ERO Subobject extension for service segment
support . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Service Segment SR-ERO Processing . . . . . . . . . . . . 6
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6
6. Management Considerations . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Segment Routing (SR) enables Traffic Engineering (TE) without relying
on a hop-by-hop signaling. It depends only on "segments" that are
advertised by Interior Gateway Protocols (IGPs). These segments made
by -
o Node Segment
o Adjacency Segment
o Anycast Segment
o IGP-Prefix Segment
Further to this list, a segment may also be identify a particular
value added service or service function (SF).
[I-D.filsfils-spring-segment-routing-use-cases] describes using local
Service-Segment to stand for a BGP-VPN service in an example. A
service-segment may also be used to represent specific treatment
offered by SR enabled node(s) in the path, a combination of node-
segment and service-segment can be used. The service segment is
local to the SR enabled node.
Dhody & Wu Expires September 7, 2015 [Page 2]
Internet-Draft Service Segment Routing March 2015
A stateful PCE can be used for computing one or more SR-TE paths
taking into account various constraints and objective functions.
Once a path is chosen, the stateful PCE can instantiate an SR-TE path
on a PCC using PCEP extensions specified in
[I-D.ietf-pce-segment-routing].
An SR-TE path is defined as a path that consists of one or more
SID(s) where each SID is associated with the identifier that
represents the node or adjacency corresponding to the SID. This
document extends the SR-TE path to use Service-SID(s) in the path as
well.
The means by which the PCE learns about the Service-SID (e.g., learnt
over a management interface or through a variety of other mechanisms)
is beyond scope of this document.
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 [RFC2119].
2.1. Terminology
The following terminologies are used in this document:
ERO: Explicit Route Object
IGP: Interior Gateway Protocol
LSR: Label Switching Router
PCC: Path Computation Client
PCE: Path Computation Element
PCEP: Path Computation Element Protocol
SF: Service Function
SFC: Service Function Chaining
SID: Segment Identifier
SR: Segment Routing
SR-ERO: Segment Routed Explicit Route Object
Dhody & Wu Expires September 7, 2015 [Page 3]
Internet-Draft Service Segment Routing March 2015
SR Path: Segment Routed Path
SR-TE: Segment Routed Traffic Engineering
3. Overview of PCEP Operation in SR Networks for Service Chaining
In SR networks, an ingress node of an SR path appends all outgoing
packets with an SR header consisting of a list of Segment IDs (SIDs).
The header has all necessary information to guide the packets from
the ingress node to the egress node of the path, and hence there is
no need for any signaling protocol. In the
[I-D.ietf-pce-segment-routing], an SID represents either a nodal
segment representing a path to a node or adjacency segment
representing path over a specific adjacency. In this document,we
allow SID also can represent a service segment representing a
specific treatment or SF.
In a PCEP session, path information is carried in the Explicit Route
Object (ERO), which consists of a sequence of subobjects. In this
document, a PCE needs to specify EROs containing SID of service
segments (or service-SID), and a PCC needs to be capable of
processing such ERO sub-objects.
The SR-ERO Subobject defined in the [I-D.ietf-pce-segment-routing]
can be used to carry SID of service segment. An SR-ERO containing
SID of service segment can be included in the same PCEP messages
specified in the [I-D.ietf-pce-segment-routing].
When a PCEP session between a PCC and a PCE is established, the
corresponding PCEP operation is same as defined in the
[I-D.ietf-pce-segment-routing].
4. Object Formats
In the [I-D.ietf-pce-segment-routing], an SR-TE path is defined as a
path that consists of one or more SID(s) where each SID is associated
with the identifier that represents the node or adjacency
corresponding to the SID. In this document, we allow the SR-TE path
to include one or more SID of service segments (called service-SID)
that are inserted along with node segments in SR-TE path. A service-
segment may also be used to represent a set of SF instances. The
service-SID is local to the node where the service resides, thus a
combination of node-segment and service-segment are used together.
Dhody & Wu Expires September 7, 2015 [Page 4]
Internet-Draft Service Segment Routing March 2015
4.1. The SR-ERO Subobject extension for service segment support
The SR-ERO Subobject is defined in section 5.3.1 of
[I-D.ietf-pce-segment-routing] and as an mandatory subobject used to
advertise SID and NAI ('Node or Adjacency Identifier') associated
with SID. In this document, we extend the existing SR-ERO Subobject
as specified in section 5.3.1 of [I-D.ietf-pce-segment-routing] to
represent service-SID of the service segment.
The SR-ERO Subobject as described in [I-D.ietf-pce-segment-routing]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | ST | Flags |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit SHOULD NOT be set, so that the subobject represents a
strict hop in the explicit route in case of service-segment.
Type
The Type is as per [I-D.ietf-pce-segment-routing].
Length
The Length is as per [I-D.ietf-pce-segment-routing].
ST
The ST (SID Type) field is set to specify service-SID. A new SID-
Type values is to be assigned.
Flags
All flags (M, C, S, F bit) are as per
[I-D.ietf-pce-segment-routing].
Dhody & Wu Expires September 7, 2015 [Page 5]
Internet-Draft Service Segment Routing March 2015
SID
The SID value represents an service segment as described in
[I-D.filsfils-spring-segment-routing-use-cases].
NAI
The NAI for service-segment may be defined in future based on the
service.
4.2. Service Segment SR-ERO Processing
When the SID represents a service segment (as per the SID Type - ST
field), its value is local to node segment offering the service.
Thus Service-SID MUST be associated with a node-SID preceding it in
the SR-ERO. Note that multiple services may be offered by the same
node, and in this case node-SID maybe followed by multiple Service-
SID. NAI value for service-SID may be defined in future.
If a service segment (or service-SID) cannot be associated with a
node segment (or node-SID), PCEP speaker MUST send a PCE error with
Error-Type = "Reception of an invalid object" and Error-Value
="Segment List Order Error".
The rest of the processing rules are as per
[I-D.ietf-pce-segment-routing].
5. Backward Compatibility
Backward Compatibility consideration described in section 8 of
[I-D.ietf-pce-segment-routing] can be applied for service segment
support as well.
6. Management Considerations
Management consideration described in section 9 of
[I-D.ietf-pce-segment-routing] can be applied to service segment
support as well.
7. Security Considerations
The security considerations described in [RFC5440] and
[I-D.ietf-pce-segment-routing] apply.
Dhody & Wu Expires September 7, 2015 [Page 6]
Internet-Draft Service Segment Routing March 2015
8. IANA Considerations
TBD.
9. References
9.1. Normative References
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions
for Segment Routing", draft-ietf-pce-segment-routing-00
(work in progress), October 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.filsfils-spring-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", draft-filsfils-
spring-segment-routing-use-cases-01 (work in progress),
October 2014.
Appendix A. Examples
Consider the below example-
+---------+
| |
| |
| |
| |
++------+ |
|| | |
|| S 2 | |
+------+ |-------+ | +------+-+ +------+
| | |-------+ | |------+ | | |
| |**|| | |**|| | |**| |
| | || S 1 | | || S 3 | | | |
| | |-------+ | |------+ | | |
+------+ +-------+-+ +------+-+ +------+
N1 N2 N3 N4
Dhody & Wu Expires September 7, 2015 [Page 7]
Internet-Draft Service Segment Routing March 2015
o N1 is Ingress;
o N4 is Egress;
o N2 has two services hosted identified as S1 and S2;
o N3 hase one service hosted identified as S3.
The SR-ERO for the SR-TE path including the service segment would be
-
[{SID_N2, SID_S1, SID_S2}, {SID_N3, SID_S3}, {SID_N4}]
Authors' Addresses
Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
Email: dhruv.ietf@gmail.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Dhody & Wu Expires September 7, 2015 [Page 8]
