[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/