Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework
RFC 8677
Document | Type |
RFC - Informational
(November 2019; No errata)
Was draft-trossen-sfc-name-based-sff (individual)
|
|
---|---|---|---|
Authors | Dirk Trossen , Debashish Purkayastha , Akbar Rahman | ||
Last updated | 2019-11-26 | ||
Stream | ISE | ||
Formats | plain text html xml pdf htmlized bibtex | ||
IETF conflict review | conflict-review-trossen-sfc-name-based-sff | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2019-05-26) | ||
IESG | IESG state | RFC 8677 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | Adrian Farrel <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
Independent Submission D. Trossen Request for Comments: 8677 InterDigital Europe, Ltd Category: Informational D. Purkayastha ISSN: 2070-1721 A. Rahman InterDigital Communications, LLC November 2019 Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework Abstract Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current Service Function Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships. This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8677. Copyright Notice Copyright (c) 2019 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 (https://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. Table of Contents 1. Introduction 2. Terminology 3. Example Use Case: 5G Control-Plane Services 4. Background 4.1. Relevant Part of SFC Architecture 4.2. Challenges with Current Framework 5. Name-Based Operation in SFF 5.1. General Idea 5.2. Name-Based Service Function Path (nSFP) 5.3. Name-Based Network Locator Map (nNLM) 5.4. Name-Based Service Function Forwarder (nSFF) 5.5. High-Level Architecture 5.6. Operational Steps 6. nSFF Forwarding Operations 6.1. nSFF Protocol Layers 6.2. nSFF Operations 6.2.1. Forwarding between nSFFs and nSFF-NRs 6.2.2. SF Registration 6.2.3. Local SF Forwarding 6.2.4. Handling of HTTP Responses 6.2.5. Remote SF Forwarding 7. IANA Considerations 8. Security Considerations 9. References 9.1. Normative References 9.2. Informative References Acknowledgements Authors' Addresses 1. Introduction The requirements on today's networks are very diverse, enabling multiple use cases such as the Internet of Things (IoT), Content Distribution, Gaming, and Network functions such as Cloud Radio Access Network (RAN) and 5G control planes based on a Service-Based Architecture (SBA). These services are deployed, provisioned, and managed using Cloud-based techniques as seen in the IT world. Virtualization of compute and storage resources is at the heart of providing (often web) services to end users with the ability to quickly provision virtualized service endpoints through, e.g., container-based techniques. This creates the ability to dynamically compose new services from existing services. It also allows an operator to move a service instance in response to user mobility or to change resource availability. When moving from a purely "distant cloud" model to one of localized micro data centers with regional,Show full document text