⌕ Поиск по атласу

IETF · RFC · RFC8677

RFC8677 · Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework

Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework

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.

Официальная английская аннотация

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.

Связи документа

Официальный источник · 2019-11-01

Полные импортированные сведения карточки
{
  "id": "RFC8677",
  "number": 8677,
  "title_en": "Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework",
  "title_ru": "",
  "summary_ru": "",
  "purpose_ru": "",
  "use_ru": "",
  "full_translation_path": "",
  "full_translation_checked_at": "",
  "full_translation_source_sha256": "",
  "architect_note_ru": "",
  "topics_ru": [],
  "translation_state": "not_prepared",
  "verification_level": "not_prepared",
  "verification_level_ru": "Русская выжимка не подготовлена",
  "verification_note_ru": "",
  "abstract_en": "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.",
  "authors": [
    "D. Trossen",
    "D. Purkayastha",
    "A. Rahman"
  ],
  "organizations": [],
  "publication_date": "2019-11-01",
  "current_status": "INFORMATIONAL",
  "current_status_ru": "Информационный",
  "publication_status": "INFORMATIONAL",
  "publication_status_ru": "Информационный",
  "lifecycle": "informational",
  "lifecycle_ru": "Справочный",
  "stream": "INDEPENDENT",
  "stream_ru": "Независимый поток",
  "area": "",
  "area_ru": "",
  "working_group": "",
  "source_draft": "draft-trossen-sfc-name-based-sff-07",
  "page_count": 24,
  "doi": "10.17487/RFC8677",
  "keywords": [
    "service function",
    "SF",
    "SFF",
    "nSFF",
    "SFC",
    "SFP",
    "NSH",
    "FQDN",
    "5G",
    "NSSAI",
    "CCNF",
    "NSSF",
    "3GPP"
  ],
  "formats": [
    "HTML",
    "TXT",
    "PDF",
    "XML"
  ],
  "relations": {
    "obsoletes": [],
    "obsoleted_by": [],
    "updates": [],
    "updated_by": [],
    "is_also": [],
    "see_also": []
  },
  "links": {
    "info": "https://www.rfc-editor.org/info/rfc8677/",
    "html": "https://www.rfc-editor.org/rfc/rfc8677.html",
    "txt": "https://www.rfc-editor.org/rfc/rfc8677.txt",
    "datatracker": "https://datatracker.ietf.org/doc/rfc8677/"
  }
}