RADIUS Attributes for NSH

Network Service Header (NSH) protocol defines the Service Function Chaining (SFC) encapsulation required to support the Service Function Chaining (SFC) Architecture . One of the components of the Network Service Header (NSH) protocol is the Service Path Identifier (SPI), which identifies a service path, another important element of the NSH protocol is the Service Index (SI), which provides location within the Service Path. When Service Providers would like to deliver customized services offers requiring Service Functions Chains, a different service chain may be required for each subscriber or group of subscribers. In order to simplify the service provisioning in this scenario, it would be useful to be able to associate the Service Path Identifier (SPI), identifying the service chain, and the appropriate Service Index (SI) identifying the location in the service path, with the customer profile. In some Broadband networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers. This document specifies two new Remote Authentication Dial-In User Service (RADIUS) attributes to carry the Service Path Identifier (SPI) and the Service Index (SI).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Network Service Header Service Function Chaining Service Function Forwarder Service Path Identifier Service Index

illustrates the network reference model for a Broadband access scenario where a NAS, acting as RADIUS Client, performs both the Service Classification and Service Forwarder Function. The Service Functions which make up the Service Chaining are part of the SP network and they are not depicted in

. ]]> Here there is a brief description of the Authentication/Authorization process between the NAS and the AAA Server. The NAS initially sends a RADIUS Access-Request message to the RADIUS server, requesting authentication. Once the RADIUS server receives the request, it validates the sending client, and if the request is approved, the AAA server replies with an Access-Accept message including a list of attribute-value pairs that describe the parameters to be used for this session. This list MAY also contain the NSH Service Path Identifier (NSH-SPI) and the NSH Service Index (NSH-SI) attributes used to identify a specific service path and the location in the service path. The NSH SPI attribute returned by AAA Server in the Access-Accept is used by the NAS to insert the traffic of the subscriber in the correct service path. A classification rule, to be associated with the SPI, can also be sent by the AAA Server as part of the list of attribute-value pairs.

This section defines the NSH Service Path Identifier (SPI) and the NSH Service Index (SI) attributes that are used in the above-mentioned scenario. The attributes design follows and refers to .

The NSH Service Path Identifier (NSH-SPI) RADIUS attribute contains the value which identifies a specific service path to be associated to a subscriber. When the NAS receives from the AAA Server the NSH-SPI attribute, the NAS MUST use the value contained in this attribute to populate the Service Path Identifier (SPI) field in the NSH Service Path header defined in . If the NAS is pre-configured with a default NSH SPI value, this value MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS, and it MAY assign a different NSH SPI. If the NAS includes the NSH-SPI attribute, but the AAA server does not recognize it, this attribute MUST be ignored by the AAA server. If the NAS does not receive the NSH-SPI attribute in the Access-Accept message, it MAY fall back to a pre-configured default NSH SPI, if any. If the NAS does not have any pre-configured NSH SPI, the traffic generated by that specific subscriber does not have to be sent across any service chain. If the NAS is pre-provisioned with a default NSH SPI and the NSH-SPI received in the Access-Accept message is different from the configured default, then the NSH-SPI received in the Access-Accept message MUST be used for the session. If an implementation includes Change-of-Authorization (CoA) messages , they could be used to modify the current specified SPI. When the NAS receives a CoA Request message containing the NSH-SPI attribute, the NAS MUST use the received NSH SPI value to re-configure the the Service Path Identifier (SPI) field in the NSH Service Path header. This allows the network administrator to modify the forwarding of the traffic of a specific subscriber. By changing the SPI value the service path used for the subscriber is modified, thus the traffic of the selected subscriber is sent across a different service chain. The NSH-SPI RADIUS attribute MUST NOT appear more than once in a message. A summary of the NSH-SPI RADIUS attribute format is shown below. The fields are transmitted from left to right.

TBD - NSH-SPI 5 The field is 3 octets, containing a 24-bit unsigned integer Service Path Identifier. The NAS acting as classifier MUST copy this value into the SPI field of the NSH Service Path Header.

The NSH Service Index (NSH-SI) RADIUS attribute contains the value which identifies the location in the service path. According to , the initial SI value SHOULD default to 255. When the NAS receives from the AAA Server the NSH-SI attribute, the NAS MUST use the value contained in this attribute to populate the Service Index (SI) field in the NSH Service Path header defined in . If the NAS is pre-configured with a default NSH SI value, this value MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS, and it MAY assign a different NSH SI. If the NAS includes the NSH-SI attribute, but the AAA server does not recognize it, this attribute MUST be ignored by the AAA server. If the NAS does not receive the NSH-SI attribute in the Access-Accept message, but it receives the NSH-SPI attribute, it MAY fall back to a pre-configured default NSH SI, if any. If the NAS receives the NSH-SPI attribute, but it does not receives the NSH-SI attribute from the AAA Server and the NAS does not have any pre-configured SI, the traffic generated by that specific subscriber MUST be dropped as this is an error condition. If the NAS is pre-provisioned with a default NSH SI and the NSH-SI received in the Access-Accept message is different from the configured default, then the NSH-SI received in the Access-Accept message MUST be used for the session. If an implementation includes Change-of-Authorization (CoA) messages , they could be used to modify the current specified NSH SI. When the NAS receives a CoA Request message containing the NSH-SI attribute, the NAS MUST use the received NSH SI value to re-configure the the Service Index (SI) field in the NSH Service Path header. The NSH-SI RADIUS attribute MUST NOT appear more than once in a message. A summary of the NSH-SI RADIUS attribute format is shown below. The fields are transmitted from left to right.

TBD - NSH-SI 3 The field is 1 octet, containing a 8-bit unsigned integer Service Index. The NAS acting as classifier MUST copy this value into the SI field of the NSH Service Path Header.

The following tables provide a guide to which attributes may be found in which kinds of packets, and in what quantity.

The following table defines the meaning of the above table entries. This attribute MUST NOT be present in the packet. Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet.

These attributes are usable within either RADIUS or Diameter . Since the attributes defined in this document have been allocated from the standard RADIUS type space, no special handling is required by Diameter entities.

The authors would like to thank Jim Guichard for his valuable comments and inputs to this document.

Per this document, IANA has assigned one new RADIUS Attribute Type in the "Radius Types" registry (currently located at http://www.iana.org/assignments/radius-types) for the following attribute: NSH-SPI TBD NSH-SI TBD

This document has no additional security considerations beyond those already identified in for the RADIUS protocol and in for CoA messages. The security considerations for NSH protocol are described in section 9 of