SPRING WG Ting. Liao
Internet-Draft Bo. Wu
Intended status: Standards Track Fangwei. Hu
Expires: April 25, 2015 ZTE Corporation
Bhumip. Khasnabish
ZTE TX Inc.
October 22, 2014
SPRING SID Allocation
draft-lw-spring-sid-allocation-00.txt
Abstract
Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF). And
a segment is identified by a Segment Routing ID(SID). This document
proposes a method that the only selected SR nodes responsible for
allocating SIDs for a SR domain to reduce SID configuration required
on all SR nodes.
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 25, 2015.
Copyright Notice
Copyright (c) 2014 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
Liao, et al. Expires April 25, 2015 [Page 1]
Internet-Draft SPRING SID Allocation October 2014
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 and Abbreviations . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SID generation and allocation . . . . . . . . . . . . . . . . 4
4.1. SID generation . . . . . . . . . . . . . . . . . . . . . 4
4.2. SID allocation . . . . . . . . . . . . . . . . . . . . . 5
5. IGP extension . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. The ISIS SID-allocation TLV . . . . . . . . . . . . . . . 6
5.2. The OSPF SID-Allocation TLV . . . . . . . . . . . . . . . 7
6. SID Allocation Ability extension . . . . . . . . . . . . . . 8
6.1. The ISIS SR Capabilities Sub-TLV extension . . . . . . . 8
6.2. The OSPF SR Capabilities TLV extension . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF). And
a segment is identified by a Segment Identifier (SID). A segment can
be encoded as a MPLS label or an IPv6 address. Typically a SID is
allocated by NMS and it very rarely changes. When the allocation has
done, each node sends out its IGP TLV extensions which had described
in [I-D.ietf-isis-segment-routing-extensions] and
[I-D.ietf-ospf-segment-routing-extensions]. With the flooding
process, each node in SR area will learn others SIDs representing.
In some situation where users expect to simply plug in a SR node and
have it automatically use Segment Routing. One of use cases is
described in [I-D.kh-spring-ip-ran-use-case], with hundreds of CSGs
in an IP RAN network, and with the complexity of the network such as
nodes adding and removing, plug and play is very necessary .
Liao, et al. Expires April 25, 2015 [Page 2]
Internet-Draft SPRING SID Allocation October 2014
This draft describes a mechanism to optimize SID allocation
operation.
2. Conventions and Abbreviations
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] .
The following notations and abbreviations are used throughout this
draft.
ASG: Aggregation Site/Service Gateway.
BS: Base Station.
CSG: Cell Site Gateway.
IP RAN: Internet Protocol RAN
LTE: Long Term Evolution.
RAN: Radio Access Network.
RNC: Radio Network Controller.
RSG: Radio Service Gateway.
SR: Segment Routing.
SID: Segment Identifiers.
3. Motivation
As described in [I-D.kh-spring-ip-ran-use-case] , the IP RAN network
scenario is shown in the figure 1.
Liao, et al. Expires April 25, 2015 [Page 3]
Internet-Draft SPRING SID Allocation October 2014
----------------
/ \
/ \
+------+ +----+ +----+ +----+ +----+
| BS |---|CSG1| |ASG1|------|RSG1|-----|RNC1|
+------+ +-+--+ +----+ +----+ +----+
| Access | Aggration |
| Domain | Domain |
+------+ +-+--+ +----+ +----+ +----+
| BS |---|CSG2| |ASG2|------|RSG2|-----|RNC2|
+------+ +----+ +----+ +----+ +----+
\ /
\ /
--------------
Figure 1 IP RAN Network Scenario
There are mostly hundreds of CSGs (Cell Site Gateway) and a few sets
of ASGs (Aggregation Site/Service Gateway) in the Access Domain of an
IP RAN network .With the increase of mobile Internet traffic, more
CSGs could be added to the Access Domain, and CSGs could be installed
in wide area. So, there is a great need to do little or no
configuration on CSGs to avoid configuration operation.
In current IP RAN implementation, typical MPLS protocols like LDP
protocol is used. If using SR replacing LDP, complexity in LDP
configuration could be greatly reduced. But in standard SR process,
each SR node should be configured with a SID by NMS, and also other
SR related parameters like SR algorithm and SID blocks.
Thus,a specific mechanism is proposed in this draft to fulfill this
requirements. Like the network in the above figure, an ASG could be
selected as a SID management node to advertise CSGs and ASGs SID
mapping to the whole SR domain.
4. SID generation and allocation
In the proposed mechanism, one or more Segment Routing Management
Nodes (SRMNs) reside at SR nodes and advertise the SID mapping
information for the various prefix associated with the SR nodes in
the SR domain.
4.1. SID generation
The NMS configure the SRGB block to the SRMN. The SRMN will generate
SIDs to the other nodes'router-ids and t the router-id of itself, the
generation principle based on the configuration of the NMS or the
Liao, et al. Expires April 25, 2015 [Page 4]
Internet-Draft SPRING SID Allocation October 2014
default generation rule, the default allocation rule MAY be based on
the numerically higher router-id with the higher SID allocated.
4.2. SID allocation
As described in section 3, when the SR node is powdered on, the IGP
protocol as default load function loaded, each node flooding out each
router information in ISIS LSP or OSPF LSA when the ISIS adjacency or
OSPF adjacency relations formed, and every node will acquire the
router-ids of other nodes from the information (such as the IP
address of router id)of IGP TLV.
Then the SRMN generates the SIDs mapping to the router-ids and
allocates the SIDs to each SR node by using the extension of SID
Allocation TLV in the IGP packet, flooding the packet out. In the
SID Allocation TLV, it carries the router-id and SID mapping, and
related algorithm type, and related multi-topology number. And in
one SID-Allocation TLV, it can carry one or more IP addresses.
Optionally, If more than one SRMN assigned by the NMS, the SRMN May
flood out another extension which indicating having the capability to
allocate SID, this extension is called the SR Allocation Ability
extension and be included in the SR capabilities. When other SR
nodes receive more than one of the SRMN advertised the extension, the
SR node could decide how to choose the Allocated SID, and the
choosing principle is based on the value of SRMN's router id or
system id, the maximum or the minimum value is chosen. When each SR
node received the IGP packet with the SID Allocation TLV, it will
know which SID is allocated to itself, and then the SR node sends out
the prefix-SID sub-TLV in its IGP packet flooding out in the IGP
area.
Then each SR node will know the other SR nodes'SID, and the related
algorithm will calculate the path to each SR node's SID.
With the automatic uniform allocation by the SRMN in the IGP area,
when a new node is added, the SRMN will know which SIDs had been
allocated, and allocate an unused SID in the SRGB to the new node's
IP address. And if the node has moved, the SRMN will delete the
related SID to the moving node's IP address and recycle this SID.
The SID uniqueness is managed on the SRMN.
If more than one SRMN assigned by the NMS, the SR Allocation Ability
extension will be used, the detail information is described in
section 4.2.
Liao, et al. Expires April 25, 2015 [Page 5]
Internet-Draft SPRING SID Allocation October 2014
5. IGP extension
The SID Allocation TLV MAY be originated by any assigned router in an
IS-IS domain or an OSPF domain. As
[I-D.ietf-ospf-segment-routing-extensions] defines OSPF extension
for the purpose of the advertisements of various SID values, new
Opaque LSAs [RFC5250] are defined in
[I-D.ietf-ospf-prefix-link-attr]. But the SID Allocation TLV is no
need to binding with the prefix of the router or re-advertised by the
router. The SID Allocation TLV may be advertised in a new Opaque
LSA.
5.1. The ISIS SID-allocation TLV
The SID Allocation TLV has Type TBD, and has the following format:
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 | Length | Flags | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Algorithm | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | SID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 ISIS SID-allocation TLV
o Type: TBD.
o 1 octet of Length: variable, in bytes.
o 1 octet of flags.
o 1 octets of Range: The 'Range' field provides the ability to
specify a range of addresses and their allocated SIDs. It is
essentially a compression scheme to allocate a continuous Prefix
and their continuous, corresponding SID/Label Block. If a single
SID is advertised then the range field MUST be set to one. For
range advertisements > 1, the number of addresses that need to be
mapped into a Prefix-SID and the starting value of the Prefix-SID
range.
o 1 octet of MT-ID: Multi-Topology ID (as defined in [RFC4915]).
Liao, et al. Expires April 25, 2015 [Page 6]
Internet-Draft SPRING SID Allocation October 2014
o 1 octet of Algorithm: one octet identifying the algorithm type the
Prefix-SID is associated. The following value is defined by this
document:
* 0: IGP metric based Shortest Path Tree (SPT).
o 4 octet of Prefix.
o 4 octet of SID: according to the flags, it contains:
* A 32 bit index defining the offset in the SID/Label space
advertised by this router using the encodings defined in
Section 3.1.
* A 24 bit label where the 20 rightmost bits are used for
encoding the label value.
5.2. The OSPF SID-Allocation TLV
The SID Allocation TLV has Type TBD, and has the following format:
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 | Length | Flags | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Algorithm | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | SID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 OSPF SID-allocation TLV
o Type: TBD.
o 1 octet of Length: variable, in bytes.
o 1 octet of flags.
o 1 octets of Range: The 'Range' field provides the ability to
specify a range of addresses and their allocated SIDs. It is
essentially a compression scheme to allocate a continuous Prefix
and their continuous, corresponding SID/Label Block. If a single
SID is advertised then the range field MUST be set to one. For
range advertisements > 1, the number of addresses that need to be
mapped into a Prefix-SID and the starting value of the Prefix-SID
range.
Liao, et al. Expires April 25, 2015 [Page 7]
Internet-Draft SPRING SID Allocation October 2014
o 1 octet of MT-ID: Multi-Topology ID (as defined in [RFC4915])
o 1 octet of Algorithm: one octet identifying the algorithm type the
Prefix-SID is associated. The following value is defined by this
document:
* 0: IGP metric based Shortest Path Tree (SPT).
o 4 octet of Prefix.
o 4 octet of SID: according to the flags, it contains:
* A 32 bit index defining the offset in the SID/Label space
advertised by this router using the encodings defined in
Section 3.1.
* A 24 bit label where the 20 rightmost bits are used for
encoding the label value.
6. SID Allocation Ability extension
With the compatibility consideration, nodes in the SR domain need to
advertise its SR data-plane capability by using SR-Capabilities TLV
in OSPF area or SR-Capabilities sub-TLV in ISIS area. So the
assigned router advertises its SID allocation capability, it may be
included in SR-Capabilities Sub-TLV of ISIS or in SR-Capabilities TLV
of OSPF, with the Special Flag to indicate it is an assigned router.
6.1. The ISIS SR Capabilities Sub-TLV extension
The ISIS SR Capabilities Sub-TLV (Type: TBD) is optional, MAY appear
multiple times inside the Router Capability TLV and has following
format:
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 | Length | Flags | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range (cont.) | SID/Label Sub-TLV (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 ISIS SR Capabilities Sub-TLV
o Type: TBD.
o 1 octet of Length: variable, in bytes.
Liao, et al. Expires April 25, 2015 [Page 8]
Internet-Draft SPRING SID Allocation October 2014
o 1 octet of flags, the following are defined:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|V|A| |
+-+-+-+-+-+-+-+-+
where:
o I-Flag: IPv4 flag. If set, then the router is capable of outgoing
IPv4 encapsulation on all interfaces.
o V-Flag: IPv6 flag. If set, then the router is capable of outgoing
IPv6 encapsulation on all interfaces.
o A-Flag: Allocation flag. If set, then the router is capable of
allocating SID capability.
3 octets of Range: defining the number of values of the range from
the starting value defined in the SID/Label Sub-TLV.
SID/Label Sub-TLV: SID/Label value as defined in
[I-D.ietf-isis-segment-routing-extensions].
6.2. The OSPF SR Capabilities TLV extension
As described in [I-D.ietf-ospf-segment-routing-extensions], the SID/
Label Range TLV as an additional router capability of SR, it is a
top-level TLV of the Router Information Opaque LSA (defined in
[RFC4970] ).
The SID/Label Range TLV MAY appear multiple times and has the
following format:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 OSPF SR Capabilities TLV
Liao, et al. Expires April 25, 2015 [Page 9]
Internet-Draft SPRING SID Allocation October 2014
o Type: TBD.
o 1 octet of Length: variable, in bytes.
o Range Size: 3 octets of the SID/label range.
o Reserved: 1 octets, where the following extension are defined:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|A| |
+-+-+-+-+-+-+-+-+
where:
o A-Flag: Allocation flag. If set, then the router is capable of
allocating SID capability.
Sub-TLVs: Initially, the only supported Sub-TLV is the SID/Label TLV
as defined in [I-D.ietf-ospf-segment-routing-extensions].
7. Security Considerations
TBD.
8. Acknowledgements
In progress.
9. IANA Considerations
TBD.
10. Normative References
[I-D.filsfils-rtgwg-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-rtgwg-
segment-routing-01 (work in progress), October 2013.
Liao, et al. Expires April 25, 2015 [Page 10]
Internet-Draft SPRING SID Allocation October 2014
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions-02 (work in progress), June 2014.
[I-D.ietf-ospf-prefix-link-attr]
Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", draft-ietf-ospf-prefix-link-attr-01 (work
in progress), September 2014.
[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-02 (work in progress), August 2014.
[I-D.kh-spring-ip-ran-use-case]
Khasnabish, B. and f. hu, "Segment Routing in IP RAN use
case", draft-kh-spring-ip-ran-use-case-01 (work in
progress), June 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
4915, June 2007.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
Authors' Addresses
Ting Liao
ZTE Corporation
No.50 Software Avenue
Nanjing, Jiangsu 210012
China
Phone: +86 25 88018801
Email: liao.ting@zte.com.cn
Liao, et al. Expires April 25, 2015 [Page 11]
Internet-Draft SPRING SID Allocation October 2014
Bo Wu
ZTE Corporation
No.50 Software Avenue
Nanjing, Jiangsu 210012
China
Phone: +86 25 88018801
Email: bo.wu@zte.com.cn
Fangwei Hu
ZTE Corporation
No.889 Bibo Rd
Shanghai 201203
China
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Bhumip Khasnabish
ZTE TX Inc.
55 Madison Avenue, Suite 160
Morristown, New Jersey 07960
USA
Phone: +001-781-752-8003
Email: bhumip.khasnabish@ztetx.com
Liao, et al. Expires April 25, 2015 [Page 12]