Internet DRAFT - draft-xu-ospf-global-label-sid-adv
draft-xu-ospf-global-label-sid-adv
Network Working Group X. Xu
Internet-Draft M. Chen
Intended status: Standards Track Huawei
Expires: July 25, 2014 January 21, 2014
Advertising Global Labels or SIDs Using OSPF
draft-xu-ospf-global-label-sid-adv-00
Abstract
Segment Routing (SR) is a new MPLS paradigm in which each SR-capable
router is required to advertise global MPLS labels or Segment IDs
(SID) for its attached prefixes by using link-state IGPs, e.g., OSPF.
One major challenge associated with such global MPLS label or SID
advertisement mechanism is how to avoid a given global MPLS label or
SID from being allocated by different routers to different prefixes.
Although such global label or SID allocation collision problem can be
addressed through manual allocation , it is error-prone and
nonautomatic therefore may not be suitable in large-scale SR network
environments. This document proposes an alternative approach for
allocating and advertising global MPLS labels or SIDs via OSPF so as
to eliminate the potential risk of label allocation collision.
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 July 25, 2014.
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
Xu & Chen Expires July 25, 2014 [Page 1]
Internet-Draft January 2014
(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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Advertising Label Bindings for Prefixes . . . . . . . . . . . 3
4. Advertising SID Bindings for Prefixes . . . . . . . . . . . . 4
5. Requesting Label Bindings for Prefixes . . . . . . . . . . . 5
6. Requesting SID Bindings for Prefixes . . . . . . . . . . . . 5
7. Advertising Mapping Server Capability . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Segment Routing (SR) [I-D.filsfils-rtgwg-segment-routing] is a new
MPLS paradigm in which each SR-capable router is required to
advertise global MPLS labels or Segment IDs (SID) for its attached
prefixes by using link-state IGPs, e.g.,
OSPF[I-D.psenak-ospf-segment-routing-extensions] . One major
challenge associated with such global MPLS label or SID advertisement
mechanism is how to avoid a given global MPLS label or SID from being
allocated by different routers to different prefixes. Although such
global label or SID allocation collision problem can be addressed
through manual allocation, it is error-prone and nonautomatic
therefore may not be suitable in large-scale SR network environments.
This document proposes an alternative approach for allocating and
advertising global MPLS labels or SIDs via OSPF so as to eliminate
the potential risk of label allocation collision. The basic idea of
this approach is to allow a particular IGP router to allocate global
MPLS labels or SIDs for those prefixes attached to each SR-capable
router and meanwhile advertise the corresponding label or SID
bindings in the IGP domain scope. That particular IGP rouer is
therefore refered to as a mapping server. As for how the mapping
Xu & Chen Expires July 25, 2014 [Page 2]
Internet-Draft January 2014
server know which prefixes need to be allocated with global labels or
SIDs, it can be achieved either by configuration on the mapping
server or by advertisement from SR-capable routers. In the multi-
area scenario where route summarization between areas is enabled, the
IP longest-match algorithm SHOULD be used by SR-capable routers when
processing label or SID bindings advertised by the mapping server,
just as the mechanism defined in [RFC5283].
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. Terminology
This memo makes use of the terms defined in
[I-D.filsfils-rtgwg-segment-routing] and [RFC4970].
3. Advertising Label Bindings for Prefixes
A new Opaque LSA [RFC5250] of type 11 (with domain-wide flooding
scope), referred to as Prefix Opaque LSA, is defined. The opaque
type of this Prefix Opaque LSA is TBD. A mapping server could use
one or more Prefix Opaque LSAs to advertise label bindings for those
prefixes which need to be allocated with global labels. One or more
Prefix TLV (type code=TBD) as shown below could be contained in a
Prefix Opaque LSA.
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=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Prefix-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix (0-4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Sub-TLVs (Variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Length: Variable.
MT-ID: Multi-Topology ID as defined in [RFC4915].
Prefix-Len: the length of the prefix in bits (i.e., 0-32).
Xu & Chen Expires July 25, 2014 [Page 3]
Internet-Draft January 2014
IPv4 Prefix: the prefix is encoded in the minimal number of octets
(i.e., 0-4) for the given number of significant bits.
A Label Binding Sub-TLV (type code=TBD) as shown below is associated
with a prefix which is contained in the Prefix TLV.
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=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved | MPLS Label (20 bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Length: 4.
P-Flag: if set, the penultimate hop router MUST perform PHP action
on the allocated MPLS label. For a given prefix, the P-Flag in
the Label Binding Sub-TLV MUST be set to the same value as that of
the P-Flag in the Label Request Sub-TLV if a label request message
(see section 5 of this document) for that prefix is received by
the mapping server.
MPLS Label: a global label which is allocated to the prefix which
is contained in the Prefix TLV.
4. Advertising SID Bindings for Prefixes
A mapping server could use one or more Prefix Opaque LSAs as defined
in Section 3 to advertise SID bindings for those prefixes which need
to be allocated with global SIDs. One or more Prefix TLV as defined
in Section 3 could be contained in a Prefix Opaque LSA.
A SID Binding Sub-TLV (type code=TBD) as shown below is associated
with a prefix which is contained in the Prefix TLV.
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=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Xu & Chen Expires July 25, 2014 [Page 4]
Internet-Draft January 2014
Length: 4.
SID: a SID for the prefix which is carried in the TLV containing
this sub-TLV.
5. Requesting Label Bindings for Prefixes
SR-capable OSPF routers could use one or more Prefix Opaque LSAs as
defined in section 3 of this document to advertise those among their
attached prefixes which need to be allocated with global labels. A
new Sub-TLV of the Prefix TLV, referred to as Label Request Sub-TLV
(type code=TBD) as shown below is associated with a prefix which is
contained in a Prefix TLV.
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=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Length: 4.
P-Flag: if set, the penultimate hop router MUST perform PHP action
on the required label.
6. Requesting SID Bindings for Prefixes
SR-capable OSPF routers could use one or more Prefix Opaque LSAs as
defined in section 3 of this document to advertise those among their
attached prefixes which need to be allocated with global SIDs. A new
Sub-TLV of the Prefix TLV, referred to as SID Request Sub-TLV (type
code=TBD and Length=0) is associated with a prefix which is contained
in a Prefix TLV.
7. Advertising Mapping Server Capability
For redundancy purpose, more than one router could be configured as
candidates for mapping servers. Each candidate for mapping servers
SHOULD advertise its capability of being a mapping servers by using
OSPF Router Capability TLV. The one with the highest priority SHOULD
be elected as the primary mapping server which is eligible to
allocate and advertise global labels or SIDs for prefixes on behalf
of SR-capable routers. The comparison of OSPF router ID breaks the
tie between two or more candidates with the same highest priority.
Xu & Chen Expires July 25, 2014 [Page 5]
Internet-Draft January 2014
Meanwhile, the one with the second highest priority SHOULD be elected
as a backup mapping server. This backup mapping server SHOULD
advertise the same label bindings as those advertised by the primary
mapping server. In this way, the unnecessary changes to the data
plane (i.e., MPLS forwarding table) of SR-capable routers can be
avoided in the event of mapping server failover.
Each candidate mapping server SHOULD advertise its capability of
being mapping servers by using an OSPF Router Informational
Capabilities TLV [RFC4970] contained in an Opaque LSA of type 11
(with domain-wide flooding scope). One of the unreserved OSPF Router
Informational Capabilities Bits is reserved for this purpose.
Furthermore, a sub-TLV (type code=TBD) as shown below is used to
convey the priority value for mapping server election.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+
Type: TBD.
Length: 1
Priority: the priority for mapping server election.
8. Acknowledgements
The authors would like to thank .
9. IANA Considerations
TBD.
10. Security Considerations
This document does not introduce any new security considerations.
11. References
11.1. Normative References
Xu & Chen Expires July 25, 2014 [Page 6]
Internet-Draft January 2014
[I-D.psenak-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., and W. Henderickx, "OSPF Extensions for
Segment Routing", draft-psenak-ospf-segment-routing-
extensions-03 (work in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[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.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008.
11.2. Informative 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.
Authors' Addresses
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
Mach Chen
Huawei
Email: mach.chen@huawei.com
Xu & Chen Expires July 25, 2014 [Page 7]
