Internet DRAFT - draft-chen-spring-segment-list-id
draft-chen-spring-segment-list-id
Networking Working Group Ran. Chen
Internet-Draft Ting. Liao
Intended status: Standards Track ZTE Corporation
Expires: April 14, 2016 October 12, 2015
Spring Segment List ID
draft-chen-spring-segment-list-id-01
Abstract
Segment Routing allows a node to steer a packet through an ordered
list of instructions, called segments. The ingress node prepends a
SR header to a packet containing a set of "segments". A segment can
represent any instruction topological or service-based.
The Segment Routing architecture can be implemented using MPLS with
no change to the forwarding plane. A segment is encoded as an MPLS
label. An ordered list of segments is encoded as a stack of labels,
but it has implications on label stack depth.
This document describes how to decrease the depth of the label stack
in order to do effective Segment Routing operation.
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 14, 2016.
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
Chen & Liao Expires April 14, 2016 [Page 1]
Internet-Draft Segment Routing October 2015
(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. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solutions considered . . . . . . . . . . . . . . . . . . . . 3
4.1. Jointing method . . . . . . . . . . . . . . . . . . . . . 3
4.1.1. Forwarding Mechanisms . . . . . . . . . . . . . . . . 5
4.2. Translation segment list to label stack method . . . . . 5
4.2.1. Forwarding Mechanisms . . . . . . . . . . . . . . . . 8
5. Distribution of a binding Segment list ID for segment list
information using BGP-LS or PCEP . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative references . . . . . . . . . . . . . . . . . . 10
8.2. Informative references . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Segment Routing (SR), as described in Draft
[I-D.ietf-spring-segment-routing]allows a node to steer a packet
through an ordered list of instructions, called segments. This can
be directly applied to the MPLS with no change on the forwarding
plane. A segment is encoded as an MPLS label. An ordered list of
segments is encoded as a stack of labels, but it has implications on
label stack depth.
There may be many specified nodes or links included in the path based
on policy, and this will greatly increase the stack depth. If the
label stack depth exceeds the LSR label stack processing
capabilities, the hardware should be upgrade to support a deeper
label stack capability.
This document describes how to decrease the depth of the label stack
in order to do effective Segment Routing operation. It does not need
to upgrade the hardware.
Chen & Liao Expires April 14, 2016 [Page 2]
Internet-Draft Segment Routing October 2015
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.
3. Terminology
SR:Segment Routing
SID:Segment Identifier
SLID: Segment List Identifier, a segment list is identified by a
Segment list ID (SLID).
SRLD:specific Readable Label Depth
4. Solutions considered
There are two solutions described in the draft, both of them do not
need to upgrade the hardware.
In this document, we define the Segment List Identifier (SLID). The
segment list is identified by a Segment list ID (SLID).
Segment list ID (SLID) is allocated by the controller. The segment
list and the SLID can be advertised to the related nodes. The
related nodes would be the jointing nodes, or all the segment nodes
that contained in the segment list, or only be advertised to the
ingress node.
o In the first case, the jointing nodes need to maintain the MPLS
forwarding entry for the SLID.
o In the second case, each segment node needs to maintain the MPLS
forwarding entry for the SLID.
o In the last case, the ingress node floods the SLID via the IGP to
all the SR nodes in the SR domain and the SR node should maintain
the SR list and the SLID mapping. Each segment nodes that
contained in the segment list would maintain the MPLS forwarding
entry for the SLID.
4.1. Jointing method
The jointing method is based on the stack processing capability of
each node. The controller should have the capability to acquire the
Chen & Liao Expires April 14, 2016 [Page 3]
Internet-Draft Segment Routing October 2015
stack processing capability of each node. It may be analyzed from
the chip's version or from the node advertising.
In the proposed mechanism, an unused ID from the SRGB is allocated by
the controller to identify the segment list which is out of the stack
processing capability.
+----------------------+
/- _| Controller | _
/ / +----------------------+_ \
/ / | | | | | \ \ \
/ / | | | | | \ \ \
+---+ / +---+ | | +---+ | +---+ \ \+---+
-------- |R1 |---/---|R3 |--|---|--|R5 |---|-|R7 |---\-- |R9 |
+---+ / +---+ | | +---+ | +---+ \ +---+
| / | / \ | \ | \ |
| / | / \ | \ | \ |
+---+ +---+ +---+ +---+ +---+
|R2 |-------|R4 |--------|R6 |-----|R8 |-------|R10|-----------
+---+ +---+ +---+ +---+ +---+
Figure 1
In this example, we assumes that:
o Each node's chip version is the same, and the stack processing
capability is 5.
o All nodes are SR capable.
o All SR nodes have the same SRGB consisting of: [100, 200]
o The operator (likely via the SDN Controller) as provisioned the
Node-SIDs 101, 102, 103, 104, 105, 106, 107, 108, 109,and 110
respectively at nodes R1, R2, R3, R4, R5, R6, R7, R8, R9 and R10.
o The controller computes a list for: {R1, R2, R4, R3, R5, R6, R8,
R7, R9, and R10}, and allocates an unused ID 100 to identify the
segment list.
o The controller advertises the binding Segment list ID (SLID) 100
for segment list {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10} to
the jointing nodes R1 and R5, or advertises the binding Segment
list ID (SLID) 100 for partitioned segment list {R1, R2, R4, R3,
Chen & Liao Expires April 14, 2016 [Page 4]
Internet-Draft Segment Routing October 2015
and R5} to the jointing nodes R1 and Segment list ID (SLID) 100
for partitioned segment list {R6, R8, R7, R9, and R10} to R5.
4.1.1. Forwarding Mechanisms
Node R1 maintains the following LIB entry:
Incoming Label: NULL
Label Operation: PUSH
Outgoing Label: {102,104,103,105,100}
Outgoing interface: port to R2
Node R5 maintains the following LIB entry:
Incoming Label: 105 &100
Ingress Operation: POP and PUSH
Outgoing Label: {106,108,107,109,110}
Outgoing interface: R6
Node R10 maintains the following LIB entry:
Incoming Label: 110
Ingress Operation: POP
Outgoing Label: NULL
Outgoing interface: NULL
Other nodes are simple as following (i.e.R7):
Incoming Label: 107&109
Ingress Operation: POP and SWAP
Outgoing Label: 109
Outgoing interface: port to R9
The following shows the progression of the packet as it enters and
leaves the SR domain when the SLID is used.
R1 encapsulates the SR header list{102,104,103,105,100}. R5 receives
the packet, and converts 100 to the following list
sequence{106,108,107,109,110}.R5 refreshs the SR header
list{106,108,107,109,110}, and then the packet is transited to
R6-R8-R7-R9-R10.
4.2. Translation segment list to label stack method
In this proposed mechanism, Segment list ID (SLID) is allocated by
the controller. The segment list and the SLID can be advertised to
all the segment nodes that contained in the segment list, or only be
advertised to the ingress node.
Chen & Liao Expires April 14, 2016 [Page 5]
Internet-Draft Segment Routing October 2015
A node N (Not the last segment node) maintains the following LIB entry:
Incoming Active Segment: SRGB_Node_N[SL-SID]
Label Operation: SWAP and PUSH (i.e. SWAP with SRGB_Node_N+1[SL-SID]
and PUSH the outer-label destination to next segment
Node_N+1)
Outgoing interface: the interface towards the next-hop along the
shortest-path to Node_N+1
Especially, if next segment is not a node segment but an adjacency
segment, the label operation would only be SWAP (i.e. SWAP with
SRGB_Node_N+1[SL-SID], Node_N+1 is adjacency to Node_N.), and
outgoing interface is determined by the adjacency.
The last segment node M maintains the following LIB entry:
Incoming Active Segment: SRGB_Node_M[SL-SID]
Label Operation: POP
Outgoing interface: NULL
Entire outgoing label stack of the packet in Node N from outer to
inner is as follows:
+-----------------------------------+
| SRGB_nexthop[Node_N+1-SID] |
+-----------------------------------+
| SRGB_Node_N+1[SL-SID] |
+-----------------------------------+
Entire outgoing label stack in ingress node from outer to inner is as
follows:
+-----------------------------------+
| SRGB_nexthop[Node_ 1-SID] |
+-----------------------------------+
| SRGB_Node_1 [SL-SID] |
+-----------------------------------+
Note:Node 1 is the first node segment.
Especially, if the first segment is not a node segment but an
adjacency segment, the label stack would only be SRGB_Node_1 [SL-
SID]. Node_1 is adjacency to ingress node.
Then, any length of the segment list can be encoded as two-level
label stacks.
Chen & Liao Expires April 14, 2016 [Page 6]
Internet-Draft Segment Routing October 2015
Let us analyze the following example:
+----------------------+
/- _| Controller | _
/ / +----------------------+_ \
/ / | | \ \
/ / | | \ \
+---+ / +---+ | +---+ +---+ \ \+---+
-------- |R0 |---/---|A1 |-----|--|R1 |-----|A2 |---\-- |R2 |
+---+ / +---+ | +---+ +---+ \ +---+
| / \ | \ |
| / \ | \ |
+---+ +---+ +---+
|R3 |--------------------|R4 |-----------------|R5 |-----------
+---+ +---+ +---+
Figure 2
An SDN Controller (SC) is connected to the network and is able to
retrieve the topology and traffic information.
We assume that:
o The operator (likely via the SDN Controller) as provisioned the
Node-SIDs 101, 102, 103, 104, 105,and 106 respectively at nodes
R0, R1, R2, R3, R4 and R5.
o The controller can steer the traffic from R0 to R5 an explicit
path R1R2R5. The controller allocates a binding Segment list ID
(SLID) 300 for segment list {R1, R2, and R5}.
o The controller advertises the binding Segment list ID (SLID) 300
for segment list {R1, R2, and R5} to all the segment nodes (i.e.
R1, R2, and R5) that contained in the segment list. Those
extensions would be described in section 5.
o In this example, all nodes are SR capable, including A1/A2/A3.
o Each SR node may have a different SRGB.
o The next-hop along the shortest-path from R0 to R1 is A1. A1 can
also be LDP/ RSVP-TE/BGP capable (optional). The next-hop along
the shortest-path from R1 to R2 is A2. A2 is either an SR node or
Chen & Liao Expires April 14, 2016 [Page 7]
Internet-Draft Segment Routing October 2015
LDP/RSVP-TE/BGP node. The next-hop along the shortest-path from
R2 to R5 is A3. A3 is either an SR node or LDP/RSVP-TE/BGP node.
o Any length of the segment list is encoded as two-level label
stacks.
4.2.1. Forwarding Mechanisms
Then, Node R1 maintains the following LIB entry:
Incoming Label: SRGB_R1 [300]
Label Operation: SWAP and PUSH
Outgoing Label: SRGB_R2 [300], SRGB_A2[103]
Outgoing interface: port to A2
Node R2 maintains the following LIB entry:
Incoming Label: SRGB_R2[300]
Label Operation: SWAP and PUSH
Outgoing Label: SRGB_R5 [300], SRGB_A3[106]
Outgoing interface: port to A2
or simple as following (because R2 knows it is the penultimate segment of the segment list):
Incoming Label: SRGB_R2 [300]
Ingress Operation: SWAP
Outgoing Label: SRGB_A 3[106]
Outgoing interface: port to A3
Node R5 maintains the following LIB entry:
Incoming Label: SRGB_R5 [106]
Ingress Operation: POP
Outgoing Label: NULL
Outgoing interface: NULL
The following shows the progression of the packet as it enters and
leaves the SR domain when the SLID is used.
Chen & Liao Expires April 14, 2016 [Page 8]
Internet-Draft Segment Routing October 2015
Packets sent by ingress R0 Packets sent by A1 Packets sent by R1
+---------------+ +----------------+
| SRGB_A1[102] | | SRGB_A2[103] |
+---------------+ +----------------+ +----------------+
| SRGB_R1[300] |------> | SRGB_R1[300] |------> | SRGB_R2[300] |------->
++=============++ ++==============++ ++==============++
|| Packet || || Packet || || Packet ||
++=============++ ++==============++ ++==============++
Packets sent by A2 Packets sent by R2 Packets sent by A3
+---------------+ +----------------+ +----------------+
| SRGB_R2[300] |------> | SRGB_A3[106] |------> | SRGB_R5[106] |
++=============++ ++==============++ ++==============++------->
|| Packet || || Packet || || Packet ||
++=============++ ++==============++ ++==============++
Packets sent by R5
++=============++
|| Packet ||
++=============++
As an optional solution, the ingress node can also encode the label
stack according to the global specific Readable label depth (SRLD).
Also, the LIB entry (for SL-SID) in each segment node can swap the
label stack according to SRLD. This option will be specified in a
future version. The global SRLD can be configured, or it can be
minimum Readable label depth of all the SR nodes. The RLD has been
specified in [I-D.kini-mpls-spring-entropy-label].
The minimum Readable label depth of all the SR nodes can be learned
via protocols.
5. Distribution of a binding Segment list ID for segment list
information using BGP-LS or PCEP
TBD.
6. IANA Considerations
TBD.
7. Security Considerations
TBD.
Chen & Liao Expires April 14, 2016 [Page 9]
Internet-Draft Segment Routing October 2015
8. References
8.1. Normative references
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-05 (work in progress), June 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-05 (work in progress),
September 2015.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing with MPLS data plane",
draft-ietf-spring-segment-routing-mpls-01 (work in
progress), May 2015.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
8.2. Informative references
[I-D.kini-mpls-spring-entropy-label]
Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., Xu, X., Henderickx, W., and J. Tantsura,
"Entropy labels for source routed stacked tunnels", draft-
kini-mpls-spring-entropy-label-03 (work in progress),
March 2015.
Authors' Addresses
Chen & Liao Expires April 14, 2016 [Page 10]
Internet-Draft Segment Routing October 2015
Ran Chen
ZTE Corporation
No.50 Software Avenue,Yuhuatai District
Nanjing, Jiangsu Province 210012
China
Phone: +86 025 88014636
Email: chen.ran@zte.com.cn
Ting Liao
ZTE Corporation
No.50 Software Avenue,Yuhuatai District
Nanjing, Jiangsu Province 210012
China
Email: liao.ting@zte.com.cn
Chen & Liao Expires April 14, 2016 [Page 11]
