Internet-Draft Li Jun Huawei June 15, 2005 Expires: December 15,2005 DHCP Option for CLF/NASS draft-lijun-dhc-clf-nass-option-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a new option for CLF(Connectivity Session Location and Repository Function) and/or NASS (Network Attachment Subsystem) discovery in an IP based NGN network. This document defines the related option and option codes. The NGN terminals can get the access network indicator via this DHCP option. Li Jun Expires December 15, 2005 [Page 1] Internet-Draft June 2005 1. Introduction In TISPAN NGN functional architecture, DHCP is used to configure the TE (NGN terminal). Such as DHCP option 120 is used to configure the P-CSCF address [RFC3361]. And also, more DHCP options are needed to carry other configuration parameters, such as access network identifier. But the existing DHCP options do not support carrying the access network identifier. The requirement for the DHCP to carry access network identifier is as follows. The NASS, Network Attachment Subsystem, in ETSI NGN Functional Architecture has the following model [NASS]: +---------------------------+ | Service Control Subsystem | | and Applications | +---------------------------+ | |e2 | +---------+ e4 +--------+ | CLF |----------------| RACS | +---------+ +--------+ / \ / \ / \ +---------+ +---------+ +---------+ +--------+ | CPECF | | NACF | | UAAF |-----| PDBF | +---------+ +---------+ +---------+ +--------+ | \ / e3 | \ / | \ / +----+ +-----+ +-----+ +---------+ | TE |---| CNG |---| ARF |-----| AMF + +----+ +-----+ +-----+ e1 +---------+ Network Access Configuration Function (NACF) Access Management Function (AMF) Connectivity Session Location and Repository Function (CLF) User Access Authorization Function (UAAF) Profile Data Base Function (PDBF) CPE Configuration Function (CPECF) In this architecture, a Service Control Subsystem may serve serveral access networks. The Service Control Subsystem need to communicate with the NASS of access network. The contact point of NASS is CLF. Li Jun Expires December 15, 2005 [Page 2] Internet-Draft June 2005 So the NACF should be able to provide to the TE an access network identifier. This information uniquely identifies the access network to which the TE is attached. When the TE accesses or registers to the Service Control Subsystem, it will carry the network identifier obtained from NACF. With this information the Service Control system should be able to locate the CLF or NASS. The transport of the access identifier depends on extension in existing DHCP protocols. This memo is an effort to define the DHCP option to carry the access network identifier, such as CLF identifier or NASS identifier. 2. Terminology The keywords "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. 3. CLF/NASS id Option This section defines the configuration option for the access network identifier. The Configuration Option contains the IPv4 address of the CLF or the fully qualified domain names of the CLF or the name of NASS. The option has three encodings, specified by the encoding byte('enc') that follows the code byte. If the encoding byte has the value 0, it is followed by the domain name of CLF, as described below (Section 3.1). If the encoding byte has the value 1, it is followed by one IPv4 addresses of CLF(Section 3.2). If the encoding byte has the value 2, it is followed by the name of NASS, as described below (Section 3.3). All implementations MUST support all three encodings. The 'Len' field indicates the total number of octets in the option following the 'Len' field, including the encoding byte. Notes: Generally, IP address or domain name of CLF is suffice to indicate the attached access network. But in some case, the operator may do not want to expose the address of CLF to TE for security consideration. So we suggest an optional encoding, name of NASS. Using the encoding, the TE will only get the name of NASS, it will not know the CLF's address, and the Service Control Subsystem may retrieve the CLF address of NASS according to the name of NASS. Li Jun Expires December 15, 2005 [Page 3] Internet-Draft June 2005 3.1 Domain Name of CLF If the 'enc' byte has a value of 0, the encoding byte is followed by a label, encoded according to Section 3.1 of RFC 1035.[RFC1035] RFC1035 encoding was chosen to accommodate future internationalized domain name mechanisms. The minimum length for this encoding is 3. The DHCP option for this encoding has the following format: Code Len enc DNS name of CLF +-----+-----+-----+-----+-----+-----+-----+--- | TBD | n | 0 | s1 | s2 | s3 | s4 | ... +-----+-----+-----+-----+-----+-----+-----+--- An example case when a CLF domain names e.g. clf1.access1.com are returned without compression will be: +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |TBD|19 | 0 | 4 |'c'|'l'|'f'|'1'| 7 |'a'|'c'|'c'|'e'|'s'|'s'|'1'| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+ | 3 |'c'|'o'|'m'| 0 | +---+---+---+---+---+ 3.2 IPv4 Address of CLF If the 'enc' byte has a value of 1, the encoding byte is followed by a IPv4 address indicating the CLF to the client. Its length is 5. The DHCP option for this encoding has the following format: Code Len enc Address +-----+-----+-----+-----+-----+-----+-----+ | TBD | 5 | 1 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+-----+ 3.3 Name of NASS If the 'enc' byte has a value of 2, the encoding byte is followed by character string indicating the name of NASS. The minimum length for this encoding is 3. The DHCP option for this encoding has the following format: Code Len enc name of NASS +-----+-----+-----+------------------+ | TBD | 5 | 1 | character string | +-----+-----+-----+------------------+ Li Jun Expires December 15, 2005 [Page 4] Internet-Draft June 2005 4. IANA Considerations The option code for CLF/NASS option MUST be assigned by IANA. 5 Normative References [NASS] Draft ETSI ES 02021 V0.4.0 NGN Functional Architecture, Network Attachment Subsystem, Release 1 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3361] Schulzrinne, "DHCPv4 Option for SIP Servers", RFC 3361, August 2002. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 6 Author's Address Li Jun Huawei Industrial Base Bantian Longgang Shenzhen 518129 P.R.C EMail: Leejun@huawei.com Fax: +86-755-28972045 Phone: +86-13823734043 7 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8 Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Li Jun Expires December 15, 2005 [Page 5]