{"draft":"draft-trossen-sfc-name-based-sff-07","doc_id":"RFC8677","title":"Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework","authors":["D. Trossen","D. Purkayastha","A. Rahman"],"format":["HTML","TEXT","PDF","XML"],"page_count":"24","pub_status":"INFORMATIONAL","status":"INFORMATIONAL","source":"INDEPENDENT","abstract":"Adoption of cloud and fog technology allows operators to deploy a\r\nsingle \"Service Function\" (SF) to multiple \"execution locations\". \r\nThe decision to steer traffic to a specific location may change\r\nfrequently based on load, proximity, etc. Under the current Service\r\nFunction Chaining (SFC) framework, steering traffic dynamically to\r\nthe different execution endpoints requires a specific \"rechaining\",\r\ni.e., a change in the service function path reflecting the different\r\nIP endpoints to be used for the new execution points.  This procedure\r\nmay be complex and take time. In order to simplify rechaining and\r\nreduce the time to complete the procedure, we discuss separating the\r\nlogical Service Function Path (SFP) from the specific execution\r\nendpoints. This can be done by identifying the SFs using a name\r\nrather than a routable IP endpoint (or Layer 2 address). This\r\ndocument describes the necessary extensions, additional functions,\r\nand protocol details in the Service Function Forwarder (SFF) to\r\nhandle name-based relationships. \r\n\r\nThis document presents InterDigital's approach to name-based SFC. It\r\ndoes not represent IETF consensus and is presented here so that the\r\nSFC community may benefit from considering this mechanism and the\r\npossibility of its use in the edge data centers.","pub_date":"November 2019","keywords":["service function","SF","SFF","nSFF","SFC","SFP","NSH","FQDN","5G","NSSAI","CCNF","NSSF","3GPP"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC8677","errata_url":null}