]> Advertising Service Functions Using OSPF China Mobile
xuxiaohu@cmss.chinamobile.com
Huawei
hongyi.huang@huawei.com
Ciena
hshah@ciena.com
Telefonica I+D
luismiguel.contrerasmurillo@telefonica.com
Routing Area LSR Working Group Sample The Segment Routing mechanism can be leveraged to realize the service path layer functionality of the Service Function Chaining (i.e, steering traffic through the service function path). This document describes how to advertise service functions and their corresponding attributes (e.g., segment ID) using OSPF. Here the OSPF means both OSPFv2 and OSPFv3.
Introduction describes a particular use case for SPRING where the Segment Routing (SR) mechanism is leveraged to realize the service path layer functionality of the Service Function Chaining (SFC), i.e, steering traffic through the service function path. To allow a service classifier to encode the segment list representing a particular service function path, the classifier needs to know on which service node(s) a given service function is located and what segment ID (SID) is used to indicate that service function on a given service node. This document describes how to advertise service functions and their corresponding attributes (e.g., SID) using OSPF. Here the OSPF means both OSPFv2 and OSPFv3 .
Terminology This memo makes use of the terms defined in and . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Advertising Service Functions and Corresponding SIDs Service nodes within the network need to advertise each service function they are offering by using a TLV within the body of the OSPF Router Information (RI) Opaque LSA . This new TLV is called as Service Function TLV. The Service Function TLV is applicable to both OSPFv2 and OSPFv3. The Service Function TLV could appear multiple times within a given Router Information (RI) Opaque LSA when more than one service function needs to be advertised by a given service node. The scope of the advertisement depends on the application but it is recommended that it SHOULD be domain-wide. Furthermore, service nodes need to allocate a corresponding SID to each service function and meanwhile advertise it by using a sub-TLV of the above Service Function TLV. In the MPLS-SR case, service nodes within the network would allocate a locally significant MPLS label to each service function they are offering. In the IPv6-SR case, service nodes within the network would allocate a locally unique link-local IPv6 address to each service function they are offering. For a given service function, the service node offering that service function could advertise the corresponding SID in the format of an MPLS label, an IPv6 address, or both.
Service Function TLV
  • Type: TBD.
  • Length: variable.
  • Service Function Identifier: A unique identifier that represents a service function within an SFC-enabled domain.
  • Sub-TLVs: contains zero or more sub-TLVs corresponding to the particular attributes of a given service function. The Service Function SID sub-TLV as defined in Section 3.2 is one such sub-TLV which is used to indicate the corresponding service function SID. Other sub-TLVs are to be defined in the future.
Service Function SID Sub-TLV
  • Type: TBD
  • Length: variable (3 or 16).
  • Value: if the Length is set to 3, the rightmost 20 bits represent an MPLS label. If the length is set to 16, the value represents an IPv6 address.
IANA Considerations This memo includes a request to IANA for allocating type codes for the Service Function sub-TLV and the Service Function SID sub-TLV.
Security Considerations This document does not introduce any new security risk.
Acknowledgements TBD.
Contributors Nan Wu
Huawei
eric.wu@huawei.com
References Normative References Extensions to OSPF for Advertising Optional Router Capabilities It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References OSPF Version 2 This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] OSPF for IPv6 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture 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. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Service Function Chaining Use Case for SPRING Huawei Huawei Ciena This document describes a particular use case for SPRING where the Segment Routing mechanism is leveraged to realize the service path layer functionality of the Service Function Chaining (i.e, steering traffic through the service function path).