Concept of NSH and Metadata: Paving the creation of new transport agonistic Service Plane in 5G era
Abstract
The Service Function Chaining (SFC) is an architecture to orchestrate network services by creating and deploying the rule-based service function chains and steering network traffic through them. One of the main tasks in SFC is the optimal composition of the service functions and checking the validation of the composed service chain based on the predefined rules.
The concept of Service function chaining is basically the abstraction of network services from underlying transport layer and create a dedicated Service plane in between Data plane and Control plane. Two key entities- Network Services Header (NSH) and Metadata are very much associated in this context. In this article, I will explain the role of these two ingredients in SFC domain for orchestrating E2E granular service chains.
Section 1:: Service Function Chaining (SFC)-Working principle
While bodies such as the 3GPP focus on the wireless and access networks, less attention has been paid to how the traffic for 5G applications is transported across metro and core networks in a way that will support and enable the delivery of new end-to-end services. Various tools will be critical in enabling transport for 5G services including Software Defined Networking (SDN), Service Function Chaining (SFC), Network Functions Virtualization (NFV), and Network Slicing.
Terminologies
Service Function (SF): A network function that provides a value-added service to traffic flows. A service function may perform its function(s) at one or more OSI layers. Service functions include: firewall, DPI, NAT, HTTP Header Enrichment function, TCP optimizer, load-balancer, IDS, IPS, NATetc.
SF Chain(SFC): An ordered list of Service Function instances. Each SF Chain is identified with a unique identifier called an SF Chain Identifier. The SFC is also called VNFFG (Virtual Network Function Forwarding Graph).
SFC Classifier (or Classifier): An entity that classifies traffic flows for service chaining according to classification rules defined in an SFC Policy Table. Frames/packets, of the flows, are then marked with the corresponding SF Chain Identifier. SFC Classifier can be embedded in an SFC Boundary (Ingress) Node or SF proxy node in which case the Classifier will do the encapsulation after getting the L2/L3 frame/packet from a Legacy SN. The SFC Classifier can run on an independent (physical or virtual) platform. The SFC classifier can be on a data path, and can also run as an application on top of a network controller.
SFC Header: A header that is embedded into the flow packet by the SFC Classifier to facilitate the forwarding of flow packets along the service function chain path. This header also allows for the transport of metadata to support various service chain related functionality.
SF Node: Denotes any node within an SFC-enabled domain that embeds one or multiple SFs.
Service Function Instance (SFI): Denotes an instantiation of a service function, such as firewall, on a service node. A service function can have multiple service instances running on the same SF node with each service instance having its own service profile.
Service Function Forwarder (SFF): Provides service layer forwarding. An SFF receives frames/packets carrying SFC header and forwards the frames/packets to the associated SF instances using information contained in the SFC header.
SF Proxy: A Network Element along the SF Chain path to facilitate the operation of legacy SF nodes. It will strip off the SFC header from the flow packet and forward the original flow packet to the SFI running on the legacy SF node. When the legacy SF node returns the packet to the Proxy, the Proxy shall correlate the packet with the SF Chain and add back the SFC header. SF Proxy is usually placed right before a legacy SF node.
Metadata: Provides contextual information about the data packets which traverse a service chain. Metadata can be used to convey contextual information not available at one location in the network to another location in the network where that information is not readily available. While primarily intended for consumption by SF(s), metadata MAY also be interpreted by other SFC entities.
SFC-enabled domain: Denotes a network (or a region thereof) that implements SFC.
SFC Policy Table: A table of classification rules. Each classification rule contains matching traffic parameters (such as 5-tuples, MAC addresses etc..) and action of the rule identifying the SFC and the service functions to be applied to the traffic.
SFC Architecture
The SFC architecture consists of management, control and data plane elements. The table below lists areas under which common SFC functional elements can be categorized. Note that the elements here are listed as separate entities from a functional perspective only. The functions may exist on separate platforms or on a single platform, which in turn may exist in physical, virtual, software or any other form factors.
The elements can be viewed as follows:
SFC management plane elements together with the control plane elements are responsible for translating user/application requests; converting requisite policies into network topology dependent paths; and disseminating steering policies to relevant forwarding nodes. SFC data plane components are responsible for carrying out the steering policies.
The role of the SF Instance Manager is to manage instantiation, configuration and decommissioning of SFs, as well as registration with SFC orchestration. Since SFs by different vendors are typically configured differently, it is necessary to have the SF Manager (usually vendor specific) to configure the SFs, and pass relevant network information (i.e. addresses, types, etc.) to SFC orchestration.
In the ONF SDN paradigm, the SFC Orchestrator requests necessary changes through the northbound interface of the Network Controller, which in turn implements the requested changes via OpenFlow. If service functions are not OpenFlow-speaking or are not under the domain of OpenFlow Network Controllers, the Orchestrator may need to interact directly with the service functions themselves or with the SF Instance Manager as shown in Figure above.
Section 2:: Network Service Header (NSH) and Metadata
NSH contains service path information and optionally metadata that are added to a packet or frame and used to create a service plane. An outer transport header is imposed, on NSH and the original packet/frame, for network forwarding.
A Service Classifier adds NSH. NSH is removed by the last SFF in the service chain or by an SF that consumes the packet.
Network Service Header Format
NSH is composed of a 4-byte Base Header, a 4-byte Service Path Header and optional Context Headers, as shown in Figure below:
NSH MD Type 1
When the Base Header specifies MD Type = 0x1, a Fixed Length Context Header (16-bytes) MUST be present immediately following the Service Path Header, as per below Figure. A Fixed Length Context Header that carries no metadata MUST be set to zero.
NSH MD Type 2
When the base header specifies MD Type = 0x2, zero or more Variable Length Context Headers MAY be added, immediately following the Service Path Header (see Figure below). Therefore, Length = 0x2, indicates that only the Base Header followed by the Service Path Header are present. The optional Variable Length Context Headers MUST be of an integer number of 4-bytes. The base header Length field MUST be used to determine the offset to locate the original packet or frame for SFC nodes that require access to that information.
NSH actions
NSH-aware nodes are the only nodes that may alter the content of NSH headers. NSH-aware nodes include: service classifiers, SFF, SF and SFC proxies. These nodes have several possible NSH-related actions:
1. Insert or remove NSH: These actions can occur at the start and end respectively of a service path. Packets are classified, and if determined to require servicing, NSH will be imposed. A service classifier MUST insert NSH at the start of an SFP. An imposed NSH MUST contain valid Base Header and Service Path Header. At the end of a service function path, an SFF, MUST be the last node operating on the service header and MUST remove NSH before forwarding or delivering the un-encapsulated packet
Multiple logical classifiers may exist within a given service path. Non-initial classifiers may re-classify data and that re-classification MAY result in the selection a different Service Function Path. When the logical classifier performs re-classification that results in a change of service path, it MUST remove the existing NSH and MUST impose a new NSH with the Base Header and Service Path Header reflecting the new service path information and set the initial SI. Metadata MAY be preserved in the new NSH.
2. Select service path: The Service Path Header provides service path information and is used by SFFs to determine correct service path selection. SFFs MUST use the Service Path Header for selecting the next SF or SFF in the service path.
3. Update NSH: SFs MUST decrement the service index by one. If an SFF receives a packet with an SPI and SI that do not correspond to a valid next hop in a valid Service Function Path, that packet MUST be dropped by the SFF.
Classifiers MAY update Context Headers if new/updated context is available.
If an SFC proxy is in use (acting on behalf of a NSH unaware service function for NSH actions), then the proxy MUST update Service Index and MAY update contexts. When an SFC proxy receives an NSH-encapsulated packet, it MUST remove NSH before forwarding it to an NSH unaware SF. When the SFC Proxy receives a packet back from an NSH unaware SF, it MUST re-encapsulates it with the correct NSH, and MUST decrement the Service Index by one.
4. Service policy selection: Service Functions derive policy (i.e., service actions such as permit or deny) selection and enforcement from NSH. Metadata shared in NSH can provide a range of service-relevant information such as traffic classification.
Figure below maps each of the four actions above to the components in the SFC architecture that can perform it.
NSH Transport Encapsulation
Once NSH is added to a packet, an outer encapsulation is used to forward the original packet and the associated metadata to the start of a service chain. The encapsulation serves two purposes:
1. Creates a topologically independent services plane. Packets are forwarded to the required services without changing the underlying network topology
2. Transit network nodes simply forward the encapsulated packets as is.
The service header is independent of the encapsulation used and is encapsulated in existing transports. The presence of NSH is indicated via protocol type or other indicator in the outer encapsulation.
Section 3:: NSH Metadata and Policy Enforcement
NSH provides the ability to carry metadata along a service path. This metadata may be derived from several sources, common examples include:
Network nodes/devices: Information provided by network nodes can indicate network-centric information (such as VRF or tenant) that may be used by service functions, or conveyed to another network node post service path egress.
External (to the network) systems: External systems, such as orchestration systems, often contain information that is valuable for service function policy decisions. In most cases, this information cannot be deduced by network nodes. For example, a cloud orchestration platform placing workloads “knows” what application is being instantiated and can communicate this information to all NSH nodes via metadata carried in the context header(s).
Service Functions: A classifier co-resident with Service Functions often perform very detailed and valuable classification. In some cases they may terminate, and be able to inspect encrypted traffic.
Regardless of the source, metadata reflects the “result” of classification. Once the data is added to NSH, it is carried along the service path, NSH-aware SFs receive the metadata, and can use that metadata for local decisions and policy enforcement. Figures below highlight the relationship between metadata and policy:
In both of the examples above, the service functions perform policy decisions based on the result of the initial classification: the SFs did not need to perform re-classification, rather they rely on a antecedent classification for local policy enforcement.
Section 4:: Role of NSH and Metadata
1. Topological Independence: Service forwarding occurs within the service plane, the underlying network topology does not require modification. NSH provides an identifier used to select the network overlay for network forwarding.
2. Service Chaining: NSH enables service chaining per [RFC7665]. NSH contains path identification information needed to realize a service path. Furthermore, NSH provides the ability to monitor and troubleshoot a service chain, end-to-end via service-specific OAM messages. NSH fields can be used by administrators (via, for example, a traffic analyzer) to verify (account, ensure correct chaining, provide reports, etc.) the path specifics of packets being forwarded along a service path.
3. NSH provides a mechanism to carry shared metadata between participating entities and service functions. The semantics of the shared metadata is communicated via a control plane, to participating nodes. Sharing the metadata allows service functions to share initial and intermediate classification results with downstream service functions saving re-classification, where enough information was enclosed.
4. NSH offers a common and standards-based header for service chaining to all network and service nodes.
5. Transport Agnostic: NSH is transport-independent. An appropriate (for a given deployment) network transport protocol can be used to transport NSH-encapsulated traffic. This transport may form an overlay network and if an existing overlay topology provides the required service path connectivity, that existing overlay may be used.
Conclusion
Service chaining is an emerging set technologies and process that enable operators to configure network-services dynamically in software without having to make changes to the network at hardware level. By routing traffic flows according to “Service graphs”, service chaining addresses the requirement for both optimization of the network through better utilization of resources; and monetization, through the provisioning of services that are tailored to customer context.
Thank you!!
Monowar Hossain
HOD, Microwave Unit (Planning and Operation)
VEON, Bangladesh
+8801962424691
Originally published at https://www.linkedin.com.
