Internet DRAFT - draft-ypal-dhcp-option-for-nsh-for-sfp
draft-ypal-dhcp-option-for-nsh-for-sfp
Network Working Group Yogendra Pal
Internet-Draft Cisco
Intended status: Standard Tracks Venkata SRG
Expires: August 16, 2016 Citrix
Vikram Menon
Ericsson
February 16, 2016
DHCP option for NSH in Service Function Path (SFP)
draft-ypal-dhcp-option-for-nsh-for-sfp-00
Abstract
This draft specifies Dynamic Host Configuration Protocol option
(both DHCPv4 and DHCPv6) for NSH aware clients participating in
the service function path(SFP) of the service chaining. As part
of this proposal SFF and SF will receive the SFP information
containing Service Path Identifier(SPI), Transport protocol and
Nexthop(NH) address of subsequent SFF/SF.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2016.
Copyright Notice
Copyright (c) 2016 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
(http://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
Pal, et al. Expires Aug 16, 2016 [Page 1]
Internet-Draft DHCP option for NSH in SFP February 2016
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements Language .......................................... 2
2. Introduction ................................................... 2
2.1. Terminology ............................................... 3
3. Model and Applicability ........................................ 3
3.1 Example service chain network ............................. 4
4. SFP DHCP Option Formats ........................................ 4
4.1. DHCPv4 Options ............................................ 7
4.2. DHCPv6 Options ............................................ 8
5. Request and Processing DHCP SFP Option ......................... 8
5.1. DHCPv4 Client Behaviour ................................... 8
5.2. DHCPv4 Server Behaviour ................................... 9
5.3. DHCPv6 Client Behaviour ................................... 9
5.4. DHCPv6 Server Behaviour ................................... 9
5.5. Geolocation Based SFP ..................................... 9
6. Security Considerations ........................................ 9
7. IANA Considerations ............................................ 9
8. Acknowledgements ............................................... 10
9. References ..................................................... 10
9.1. Normative References ...................................... 10
9.2. Informative References .................................... 10
1. Requirements Language
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 RFC 2119 [RFC2119].
2. Introduction
In NSH aware service chaining model, SFF needs to be provisioned with
SFP information. In the current environment, the operator
manually provisions each network elements(SFF) with SFP information.
This does not scale well when on-demand service functions are introduced
and brought down in virtualized networks in cloud, datacenter, and so
Pal, et al. Expires Aug 16, 2016 [Page 2]
Internet-Draft DHCP option for NSH in SFP February 2016
forth deployments. This draft is trying to automate this network rollout
of service chaining using the DHCP option. Each SFF willing to
participate in NSH aware service chain model will indicate its interest
to the DHCP server for SFP and gets provisioned accordingly from the
DHCP server.
2.1. Terminology
This document uses the terminology defined in draft-ietf-sfc-nsh with
respect to service function chain.
DHCP client: A DHCP [1] client is an Internet host that uses DHCP to
obtain configuration parameters such as a network address.
DHCP server: A DHCP server is an Internet host that returns
configuration parameters to DHCP clients.
Service Function Forwarder (SFF): A service function forwarder is
responsible for delivering traffic received from the SFCNF to one
or more connected service functions, and from service functions to
the SFC network forwarder(SFCNF).
Service Function (SF): A function that is responsible for specific
treatment of received packets. A service function can act at the
network layer or other OSI layers. A service function can be a
virtual instance or be embedded in a physical network element.
One of multiple service functions can be embedded in the same
network element. Multiple instances of the service function can
be enabled in the same administrative domain.
Service Function Path (SFP): The instantiation of a SFC in the
network. Packets follow a service function path from a classifier
through the requisite service functions.
3. Model and Applicability
In service chaining model, SFC controller will provision SFF with
details of service function paths SFP(s). In order to provision SFP
details to SFF(s), controller needs some mechanism to configure the
SFF. DHCP protocol is one of the existing mechanism for provisioning
various network information to any DHCP clients.
Existing DHCP version 4 and 6 will be extended to incorporate option
of provisioning dynamically SFP details to SFF. In this case,
controller can be considered to act as DHCP server.
Pal, et al. Expires Aug 16, 2016 [Page 3]
Internet-Draft DHCP option for NSH in SFP February 2016
3.1 Example service chain network
See Figure 1, depicting SFF (DHCP clients) interacting with SFC
controller (DHCP server) to register and getting provisioned
with SFP details.
+-------------------------------------------------+
| SFC Control Plane |
| (DHCP Server) |
+-------------------------------------------------+
^ ^
| |
+-------------------------------------------------+
| DHCP protocol exchanges |
| provisioning Service function Path (SFP) |
| (SFP1 + SFP2) to SFF Clients |
+-------------------------------------------------+
| |
| |
v v
+--------+ +---------+
| SFF | ---(SFP1)---> | SFF |
|(DHCPv4 | <---(SFP2)--- | (DHCPv6 |
| client)| ........................... | client)|
+--------+ +---------+
Figure 1: SFF enabled DHCP clients in service chaining
4. SFP DHCP Option Formats
The SFP information is composed of a generic SFP header, followed
by one or more SFP entries, as shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <SFP Entries> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SFP Information
Pal, et al. Expires Aug 16, 2016 [Page 4]
Internet-Draft DHCP option for NSH in SFP February 2016
Version: SFP Information version (0), 1 Octet.
Count: This field indicates total number of SFP entries.
This is 1 octet.
Reserved: MUST be set zero.
SFP Entries: One or more SFP entries, each composed Transport type,
Protocol ID, SP header (SPH) and followed by one or
more SFP-NH entries, as shown in Figure 3.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transport Type | Count | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path (SP) Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <SFP-NH Entries> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SFP Entry
Transport Type: This field indicates the type of transport layer
attribute. Examples: L2, L3, L4. Values for transport type are
following:
-------------------------------------
| Transport Types| Value(in decimal)|
-------------------------------------
| L2 | 2 |
| L3 | 3 |
| L4 | 4 |
-------------------------------------
Table 1: Transport Types
Count: This field indicates total number of SFP-NH entries
with the given Transport Type, Protocol ID and SP Header.
This is 1 octet.
Protocol ID: This field indicates the actual protocol layer
encapsulating the NSH. This is to be read and understood in
accordance with Transport Type field. Values for this field
are following:
-------------------------------------
| Protocol ID | Value(in decimal)|
-------------------------------------
| Ethernet | 35151 |
| VXLAN-gpe | 4790 |
| GRE | 47 |
| UDP | 6633 |
-------------------------------------
Table 2: Protocol ID
Pal, et al. Expires Aug 16, 2016 [Page 5]
Internet-Draft DHCP option for NSH in SFP February 2016
Example of {Transport Type, Protocol ID} SHOULD be seen as
below:
-------------------------------------
| Transport Type | Protocol ID |
-------------------------------------
| 2 | 35151 |
| 2 | 4790 |
| 3 | 47 |
| 4 | 6633 |
-------------------------------------
Table 3: Association of Transport
Type and Protocol ID
SP header is composed of Service Path ID and Service Index,
shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Service Function (SF) Header
Service Path ID (SPI): 24 bits
Service Index (SI): 8 bits
As defined in draft
[https://tools.ietf.org/html/draft-ietf-sfc-nsh-02#section-3.3]
SFP-NH Entries: One or more SFP-NH entries, as shown in Figure 5.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFP-NH Type | Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <SFP-NH Addresses> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SFP-NH Entry
Pal, et al. Expires Aug 16, 2016 [Page 6]
Internet-Draft DHCP option for NSH in SFP February 2016
SFP-NH Type: Nexthop address types (1 Octet).
-------------------------------------
| SFP-NH Type | Value (in decimal)|
-------------------------------------
| IPv4 | 1 |
| IPv6 | 2 |
| Ethernet | 3 |
-------------------------------------
Table 4: SFP-NH Type Values
Count: This field indicates total number of SFP-NH addresses
with the given SFP-NH type. This is 1 octet
Reserved: MUST be set zero.
SFP-NH addresses: One or more SFP nexthop addresses of same
SFP-NH type.
4.1 DHCPv4 Options
4.1.1 DHCPv4 NSH SFP Option
The NSH SFP option can be used by the client and server during the
initial four message exchanges (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST,
and DHCPACK) or during two message exchange (DHCPINFORM and DHCPACK)
to configure the SFP details to SFF DHCP clients (i.e SFF will
receive SFP details along with other DHCP configuration parameters).
The format of NSH SFP option for DHCPv4 is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code=214 | Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SFP Information .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DHCPv4 NSH SFP option
Code: OPTION_NSH_SFP (TBD: IANA consideration)
Len: Length of SFP Information in 32 bit words.
Reserved: MUST be set zero.
SFP Info: Service function path details.
Refer Section 4 to see format and details of SFP information.
Pal, et al. Expires Aug 16, 2016 [Page 7]
Internet-Draft DHCP option for NSH in SFP February 2016
4.2 DHCPv6 Options
4.2.1 DHCPv6 NSH SFP Option
The NSH SFP option is used by the server to configure the service
function path details to SFF DHCP clients (i.e clients showing
interest in participating in service chaining SFP as part of initial
4-way exchange or Rapid commit exchange).
The format of NSH SFP option for DHCPv6 is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NSH_SFP | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. SFP Info .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHCPv6 NSH SFP option
option-code: OPTION_NSH_SFP (TBD: IANA consideration).
option-len: Length of SFP Information in octets.
SFP Info: Service function path details.
Refer section 4 to see format and details of SFP information.
5. Request and Processing DHCP SFP Option
In the service chaining model, SFF DHCP clients willing to participate
in SFP can request SFP information from the DHCP server using the
OPTION_NSH_SFP option. Details of this request in DHCPv4 and DHCPv6
are detailed in below sections.
5.1. DHCPv4 Client Behaviour
DHCPv4 client enabled with the capability of doing SFF/SF role in SFP
MUST request for SFP information in DHCPDISCOVER and DHCPREQUEST of
DHCPv4 protocol exchanges. Client behaviour is detailed below.
5.1.1 Requesting OPTION_NSH_SFP
SFF enabled DHCPv4 client interested in SFP MUST send the
OPTION_NSH_SFP option to the DHCPv4 server along with other
options in Parameter Request List (PRL).
A client configured from beginning to act as SFF MUST include the
OPTION_NSH_SFP option in both DHCPDISCOVER and DHCPREQUEST to inform
the server about the options client is interested in. Whereas, if the
client is configured latter to act as SFF after initial exchanges, it
MUST include OPTION_NSH_SFP option in the DHCPINFORM message to inform
the server.
Pal, et al. Expires Aug 16, 2016 [Page 8]
Internet-Draft DHCP option for NSH in SFP February 2016
5.2. DHCPv4 Server Behaviour
A DHCPv4 server if configured to handle service chaining, SHOULD
provision the SFF clients with SFP, as per its administrative policy.
A server can receive requests for OPTION_NSH_SFP option from clients
in different message (DHCPDISCOVER and DHCPREQUEST) exchanges.
DHCPv4 server SHOULD inform the client with the option OPTION_NSH_SFP
and SFP information in both DHCPOFFER and DHCPACK messages as a response
to the DHCP client's DHCPDISCOVER and DHCPREQUEST respectively. If the
DHCPv4 server receives the option OPTION_NSH_SFP during DHCPINFORM
exchange, it SHOULD process and respond back as per administrative
policy (server MAY choose to act as per the host requirement document).
NSH SFP option sent to client is detailed in section 4.1.1
5.3. DHCPv6 Client Behaviour
DHCPv6 client enabled with capability of doing SFF/SF role in SFP can
request for SFP information at different stages of DHCPv6 protocol
exchanges. Client behaviour is detailed below.
5.3.1 Requesting OPTION_NSH_SFP
SFF enabled DHCPv6 client interested in SFP MUST send the
OPTION_NSH_SFP option to the DHCPv6 server along with other
options in Option Request Option (ORO).
A client configured from beginning to act as SFF MUST include an
Option Request option in a Solicit, Request, Renew, Rebind, Confirm
message to inform the server about options the client wants the server
to send to the client. Whereas if the client is configured latter to
act as SFF MUST include an OPO in the Information-request
message to inform the server about options client wants server to send.
5.4. DHCPv6 Server Behaviour
A DHCPv6 server if configured to handle service chaining, SHOULD
provision the SFF clients as per the administrative policy.
A server can receive request for OPTION_NSH_SFP option from clients,
in different messages (Solicit, Request, Renew, Rebind, Confirm or
Information-request).
Whenever server detects any change is required in the SFP path, it
will inform the clients using Reconfigure Message.
5.4.1 Processing OPTION_NSH_SFP Request
A server receiving the option OPTION_NSH_SFP in Solicit, Request, Renew,
Rebind, Confirm or Information-request will process this request and
SHOULD respond back to exchange with NSH SFP option as detailed in
section 4.2.1
Pal, et al. Expires Aug 16, 2016 [Page 9]
Internet-Draft DHCP option for NSH in SFP February 2016
5.4.2 Notifying update in SFP path to SFF
Any update to notify about change in service chain path is notified
to SFF client using Reconfigure Message as defined in section 22.19 of
[RFC3315].
5.5. Geolocation Based SFP
In certain cloud deployment scenarios, operator will like to know the
details of SFF location to provide information to local authority towards
integrity of resources and data moving across the SFF. In such scenarios,
SFF sends option OPTION_NSH_SFP along with geolocation option to DHCP
server.
In order to achieve this, the DHCP SFF clients SHOULD include the
GeoConf option as per RFC6225 and OPTION_GEOCONF_CIVIC option as per
RFC4776 for DHCPv4 and DHCPv6 respectively, along with the OPTION_NSH_SFP
option in DHCPDISCOVER, DHCPREQUEST, DHCPINFORM requests of DHCPv4 and
in Solicit, Request, Renew, Rebind, Confirm or Information-request in
DHCPv6 exchanges.
6. Security Considerations
Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and
requesting client can discover the SFP information.
To minimize the unintended exposure of SFP, the OPTION_NSH_SFP
option SHOULD be returned by DHCP servers only when the DHCP client
has included this option in its request (Section 3.5 of [RFC2131],
Section 9.8 of [RFC2132]).
Where critical decisions might be based on the value of this option,
DHCP authentication as defined in "Authentication for DHCP Messages"
[RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
[RFC3315] SHOULD be used to protect the integrity of the DHCP
options.
Link-layer confidentiality and integrity protection may also be
employed to reduce the risk of location disclosure and tampering.
7. IANA Considerations
Request to IANA for assignment of values for following.
Table 1: Transport Types values.
Table 2: Protocol ID values.
Table 4: SFP-NH Type values.
Code: OPTION_NSH_SFP for DHCPv4.
option-code: OPTION_NSH_SFP for DHCPv6.
Pal, et al. Expires Aug 16, 2016 [Page 10]
Internet-Draft DHCP option for NSH in SFP February 2016
8. Acknowledgements
9. References
9.1. Normative References
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-00 (work in progress), March 2015.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for
Definition of New DHCP Options and Message Types",
BCP 43, RFC 2939, September 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6",
July 2003.
[RFC6225] J. Polk., M. Linsner., M. Thomson., B. Aboba, Ed.,
"Dynamic Host Configuration Protocol Options for
Coordinate-Based Location Configuration Information",
July 2011.
9.2. Informative References
[I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-05 (work
in progress), February 2015.
[I-D.draft-ietf-sfc-control-plane-00]
Li, et al., "Service Function Chaining (SFC) Control Plane
Components & Requirements",
draft-ietf-sfc-control-plane-00(work in progress),
August 2015.
Pal, et al. Expires Aug 15, 2016 [Page 11]
Internet-Draft DHCP option for NSH in SFP February 2016
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, August 2014.
Author's Address
Yogendra Pal
Cisco Systems, Inc
India
EMail: yogpal@cisco.com
VenkataSubbaRao Gorrepati
Citrix
Bangalore
India
EMail: venkatasubbarao.gorrepati@citrix.com
Vikram Menon
Ericsson
Bangalore
India
EMail: vikram.menon@ericsson.com
