Internet DRAFT - draft-lw-spring-sid-allocation
draft-lw-spring-sid-allocation
SPRING WG Ting. Liao
Internet-Draft Bo. Wu
Intended status: Standards Track Fangwei. Hu
Expires: January 7, 2016 ZTE Corporation
Bhumip. Khasnabish
ZTE TX Inc.
July 6, 2015
SPRING SID Allocation
draft-lw-spring-sid-allocation-02.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 to reduce the SID configuration in a SR domain.
Only the selected SR nodes which named Segment Routing Management
Nodes (SRMNs) are configured by NMS, while other SRs in the domain
need zero-SR-configuration.
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 January 7, 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
Liao, et al. Expires January 7, 2016 [Page 1]
Internet-Draft SPRING SID Allocation July 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 and Abbreviations . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SID generation and allocation . . . . . . . . . . . . . . . . 4
4.1. SID generation . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 11
10. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
configured by NMS and it very rarely changes. When the SID
configured, each node could send out its IGP TLV extensions which had
described in [I-D.ietf-isis-segment-routing-extensions] and
[I-D.ietf-ospf-segment-routing-extensions].
In some situation where users expect to simply plug in a SR node and
have it automatically enable Segment Routing. One of the use cases
is described in [I-D.kh-spring-ip-ran-use-case], with hundreds of
CSGs in an IP RAN network, the configuration assigned by NMS could be
very complexity. And with the complexity of the network such as
nodes adding and removing, the management on NMS is a hard work. If
the CSGs can plug and play, it will be very useful. And the CSGs
Liao, et al. Expires January 7, 2016 [Page 2]
Internet-Draft SPRING SID Allocation July 2015
could be uploaded with zero-touch currently, by generating the ip
address from MAC by default algorithm and with the ospf process
default uploaded, have a mechanism to ensure the uniqueness of ip.
Then the CSGs could be connected, and the topology will be collected
by the ASGs. With the mechanism described in this draft, there is no
SR configuration on the CSGs, the CSGs could be zero-touch still,
reduce the complexity of SR related configuration and reduce the
complexity of NMS.
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
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 January 7, 2016 [Page 3]
Internet-Draft SPRING SID Allocation July 2015
----------------
/ \
/ \
+------+ +----+ +----+ +----+ +----+
| BS |---|CSG1| |ASG1|------|RSG1|-----|RNC1|
+------+ +-+--+ +----+ +----+ +----+
| Access | Aggration |
| Domain | Domain |
+------+ +-+--+ +----+ +----+ +----+
| BS |---|CSG2| |ASG2|------|RSG2|-----|RNC2|
+------+ +----+ +----+ +----+ +----+
\ /
\ /
--------------
Figure 1 IP RAN Network Scenario
There are 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, as the CSGs could be uploaded with
zero-touch, by generating the ip address from MAC by default
algorithm and with the ospf process default uploaded, have a
mechanism to ensure the uniqueness of ip. Then the CSGs could be
connected, and the topology will be collected by the ASGs. ASGs are
configured by NMS, and the configurations on CSGs are configured by
ASGs, typical MPLS protocols like LDP protocol is used. With SR
replacing LDP, complexity in LDP configuration could be greatly
reduced. But in current SR process, each SR node should be
configured by NMS, including the SR related configurations such as
SIDs and SR algorithm and SR global blocks.
If the configuration on CSGs still need to be came from ASGs, a
specific mechanism is proposed in this draft to fulfill this
requirement. Like the network in the above figure, an ASG or both
the ASGs 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.
Liao, et al. Expires January 7, 2016 [Page 4]
Internet-Draft SPRING SID Allocation July 2015
4.1. SID generation
The NMS configure the SRGB block to the SRMN. The SRMN will generate
SIDs to other nodes'router-ids and to the router-id of itself, the
generation principle based on the configuration of the NMS or the
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 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 or the SID Binding TLV(as described in
[I-D.ietf-isis-segment-routing-extensions] and
[I-D.ietf-ospf-segment-routing-extensions]. )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 SRMNs 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, the choosing
principle is based on the value of SRMNs' router id or system id, the
maximum or the minimum value is chosen, and the SID allocated by the
maximum or minimum id's SRMN be 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.
Liao, et al. Expires January 7, 2016 [Page 5]
Internet-Draft SPRING SID Allocation July 2015
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.
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
Liao, et al. Expires January 7, 2016 [Page 6]
Internet-Draft SPRING SID Allocation July 2015
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]).
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
Liao, et al. Expires January 7, 2016 [Page 7]
Internet-Draft SPRING SID Allocation July 2015
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])
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:
Liao, et al. Expires January 7, 2016 [Page 8]
Internet-Draft SPRING SID Allocation July 2015
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.
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:
Liao, et al. Expires January 7, 2016 [Page 9]
Internet-Draft SPRING SID Allocation July 2015
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
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.
Liao, et al. Expires January 7, 2016 [Page 10]
Internet-Draft SPRING SID Allocation July 2015
9. IANA Considerations
TBD.
10. Normative References
[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-05 (work in progress), June 2015.
[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-06 (work
in progress), June 2015.
[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. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-03 (work in progress), May 2015.
[I-D.kh-spring-ip-ran-use-case]
Khasnabish, B., hu, f., and L. Contreras, "Segment Routing
in IP RAN use case", draft-kh-spring-ip-ran-use-case-02
(work in progress), November 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.
Liao, et al. Expires January 7, 2016 [Page 11]
Internet-Draft SPRING SID Allocation July 2015
Authors' Addresses
Ting Liao
ZTE Corporation
No.50 Software Avenue
Nanjing, Jiangsu 210012
China
Phone: +86 25 88018801
Email: liao.ting@zte.com.cn
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 January 7, 2016 [Page 12]
