draft-ietf-dime-extended-naptr-06.txt   draft-ietf-dime-extended-naptr-07.txt 
Diameter Maintenance and M. Jones Diameter Maintenance and Extensions M. Jones
Extensions (DIME) Bridgewater Systems (DIME) Bridgewater Systems
Internet-Draft J. Korhonen Internet-Draft J. Korhonen
Updates: 3588 (if approved) Nokia Siemens Networks Updates: 3588 (if approved) Nokia Siemens Networks
Intended status: Standards Track L. Morand Intended status: Standards Track L. Morand
Expires: September 8, 2011 Orange Labs Expires: November 10, 2011 Orange Labs
March 7, 2011 May 9, 2011
Diameter S-NAPTR Usage Diameter S-NAPTR Usage
draft-ietf-dime-extended-naptr-06 draft-ietf-dime-extended-naptr-07
Abstract Abstract
The Diameter base protocol specifies mechanisms whereby a given realm The Diameter base protocol specifies mechanisms whereby a given realm
may advertise Diameter nodes and the supported transport protocol. may advertise Diameter nodes and the supported transport protocol.
However, these mechanisms do not reveal the Diameter applications However, these mechanisms do not reveal the Diameter applications
that each node supports. A peer outside the realm would have to that each node supports. A peer outside the realm would have to
perform a Diameter capability exchange with every node until it perform a Diameter capability exchange with every node until it
discovers one that supports the required application. This document discovers one that supports the required application. This document
updates [RFC3588] and describes an improvement using an extended updates [RFC3588] and describes an improvement using an extended
format for the Straightforward-NAPTR (S-NAPTR) Application Service format for the Straightforward-Naming Authority Pointer (S-NAPTR)
Tag that allows for discovery of the supported applications without Application Service Tag that allows for discovery of the supported
doing Diameter capability exchange beforehand. applications without doing Diameter capability exchange beforehand.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2011. This Internet-Draft will expire on November 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 6 6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. IETF Diameter Application Service Tags . . . . . . . . . . 7 7.1. IETF Diameter Application Service Tags . . . . . . . . . . 7
7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 7 7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 7
7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 8 7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 8
7.4. Vendor-Specific Diameter Application Service Tags . . . . 8 7.4. Vendor-Specific Diameter Application Service Tags . . . . 8
7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 9 7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Normative References . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Diameter base protocol [RFC3588] specifies three mechanisms for The Diameter base protocol [RFC3588] specifies three mechanisms for
the Diameter peer discovery. One of these involves the Diameter the Diameter peer discovery. One of these involves the Diameter
implementation performing a NAPTR query [RFC3403] for a server in a implementation performing a Naming Authority Pointer (NAPTR) query
particular realm. These NAPTR records provide a mapping from a [RFC3403] for a server in a particular realm. These NAPTR records
domain, to the SRV record [RFC2782] or A/AAAA record provide a mapping from a domain, to the SRV record [RFC2782] or
[RFC1035][RFC3596] for contacting a server with the specific A/AAAA record [RFC1035][RFC3596] for contacting a server with the
transport protocol in the NAPTR services field. specific transport protocol in the NAPTR services field.
The extended NAPTR usage for Diameter peer discovery defined by this The extended NAPTR usage for Diameter peer discovery defined by this
document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic
Delegation Discovery System (DDDS) Application defined in [RFC3958]. Delegation Discovery System (DDDS) Application defined in [RFC3958].
This document updates the Diameter peer discovery procedure described This document updates the Diameter peer discovery procedure described
in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service
and Application Protocol Tag values that permit the discovery of and Application Protocol Tag values that permit the discovery of
Diameter peers that support a specific Diameter application and Diameter peers that support a specific Diameter application and
transport protocol. transport protocol.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
For example, a NAPTR service field value of: For example, a NAPTR service field value of:
'aaa+ap16777251:diameter.sctp' 'aaa+ap16777251:diameter.sctp'
Means that the Diameter node in the SRV or A/AAAA record supports Means that the Diameter node in the SRV or A/AAAA record supports
the Diameter 3GPP S6a Application ('16777251') and SCTP as the the Diameter 3GPP S6a Application ('16777251') and SCTP as the
transport protocol. transport protocol.
4. Backwards Compatibility 4. Backwards Compatibility
DNS administrators SHOULD also provision legacy RFC 3588 style NAPTR Domain Name System (DNS) administrators SHOULD also provision legacy
records [RFC2915] in order to guarantee backwards compatibility with RFC 3588 style NAPTR records [RFC3403] in order to guarantee
legacy RFC 3588 compliant Diameter peers. If the DNS administrator backwards compatibility with legacy RFC 3588 compliant Diameter
provisions both extended S-NAPTR records as defined in this peers. If the DNS administrator provisions both extended S-NAPTR
specification and legacy RFC 3588 NAPTR records, then the extended records as defined in this specification and legacy RFC 3588 NAPTR
S-NAPTR records MUST have higher priority (e.g. lower order and/or records, then the extended S-NAPTR records MUST have higher priority
preference values) than legacy NAPTR records. (e.g. lower order and/or preference values) than legacy NAPTR
records.
5. Extended NAPTR-based Diameter Peer Discovery 5. Extended NAPTR-based Diameter Peer Discovery
The Diameter Peer Discovery principles are described in Section 5.2 The Diameter Peer Discovery principles are described in Section 5.2
of [RFC3588]. This specification updates the NAPTR query procedure of [RFC3588]. This specification updates the NAPTR query procedure
in the Diameter peer discovery mechanism by allowing the querying in the Diameter peer discovery mechanism by allowing the querying
node to determine which applications are supported by resolved node to determine which applications are supported by resolved
Diameter peers. Diameter peers.
The extended format NAPTR records provide a mapping from a domain to The extended format NAPTR records provide a mapping from a domain to
skipping to change at page 5, line 47 skipping to change at page 5, line 48
The assumption for this mechanism to work is that the DNS The assumption for this mechanism to work is that the DNS
administrator of the queried domain has first provisioned the DNS administrator of the queried domain has first provisioned the DNS
with extended format NAPTR entries. The steps below replace the with extended format NAPTR entries. The steps below replace the
NAPTR query procedure steps in Section 5.2 of [RFC3588]. NAPTR query procedure steps in Section 5.2 of [RFC3588].
a. The Diameter implementation performs a NAPTR query for a server in a. The Diameter implementation performs a NAPTR query for a server in
a particular realm. The Diameter implementation has to know in a particular realm. The Diameter implementation has to know in
advance which realm to look for a Diameter agent in and which advance which realm to look for a Diameter agent in and which
Application Identifier it is interested in. For example, the Application Identifier it is interested in. For example, the
realm could be deduced from the NAI in the User-Name AVP or realm could be deduced from the Network Access Identifier (NAI) in
extracted from the Destination-Realm AVP. the User-Name AVP or extracted from the Destination-Realm AVP.
b. If the returned NAPTR service fields contain entries formatted as b. If the returned NAPTR service fields contain entries formatted as
"aaa+apX:Y" where "X" indicates the Application Identifier and "Y" "aaa+apX:Y" where "X" indicates the Application Identifier and "Y"
indicates the supported transport protocol(s), the target realm indicates the supported transport protocol(s), the target realm
supports the extended format for NAPTR-based Diameter peer supports the extended format for NAPTR-based Diameter peer
discovery defined in this document. discovery defined in this document.
If "X" contains the required Application Identifier and "Y" If "X" contains the required Application Identifier and "Y"
matches a supported transport protocol, the Diameter matches a supported transport protocol, the Diameter
implementation resolves the "replacement" field entry to a implementation resolves the "replacement" field entry to a
skipping to change at page 6, line 44 skipping to change at page 6, line 44
d. If the target realm does not support NAPTR-based Diameter peer d. If the target realm does not support NAPTR-based Diameter peer
discovery, the client proceeds with the next peer discovery discovery, the client proceeds with the next peer discovery
mechanism described in Section 5.2 of [RFC3588]. mechanism described in Section 5.2 of [RFC3588].
6. Usage Guidelines 6. Usage Guidelines
Diameter is a peer to peer protocol whereas most of the applications Diameter is a peer to peer protocol whereas most of the applications
that extend the base protocol behave like client/server applications. that extend the base protocol behave like client/server applications.
The role of the peer is not advertised in the NAPTR tags and not even The role of the peer is not advertised in the NAPTR tags and not even
communicated during Diameter capability negotiation (CER/CEA). For communicated during Diameter capability negotiation (Capabilities-
this reason, NAPTR-based Diameter peer discovery for an application Exchange-Request and Capabilities-Exchange-Answer message exchange).
defining client/server roles should only be used by a client to For this reason, NAPTR-based Diameter peer discovery for an
discover servers. application defining client/server roles should only be used by a
client to discover servers.
7. IANA Considerations 7. IANA Considerations
7.1. IETF Diameter Application Service Tags 7.1. IETF Diameter Application Service Tags
IANA is requested to reserve a value of "aaa" for Diameter in the IANA is requested to reserve a value of "aaa" for Diameter in the
S-NAPTR Application Service Tag registry created by [RFC3958]. IANA S-NAPTR Application Service Tag registry created by [RFC3958]. IANA
is also requested to reserve the following S-NAPTR Application is also requested to reserve the following S-NAPTR Application
Service Tags for existing IETF Diameter applications in the same Service Tags for existing IETF Diameter applications in the same
registry. registry.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
diameter.sctp") were also contributed to RFC3588bis to ensure that it diameter.sctp") were also contributed to RFC3588bis to ensure that it
would be functionally complete if it got published first and this would be functionally complete if it got published first and this
draft would come along later to add the application-specific S-NAPTR draft would come along later to add the application-specific S-NAPTR
entries (e.g."aaa+ap5:diameter.sctp"). entries (e.g."aaa+ap5:diameter.sctp").
Depending on the publication order, the S-NAPTR Application Service Depending on the publication order, the S-NAPTR Application Service
Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags
values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need
to be removed either from this draft or RFC3588bis. to be removed either from this draft or RFC3588bis.
11. References 11. Normative References
11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
skipping to change at page 11, line 34 skipping to change at page 11, line 31
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
and G. Zorn, "Diameter Quality-of-Service Application", and G. Zorn, "Diameter Quality-of-Service Application",
RFC 5866, May 2010. RFC 5866, May 2010.
[TS29.215] [TS29.215]
3rd Generation Partnership Project, "3GPP TS 29.215; 3rd Generation Partnership Project, "3GPP TS 29.215;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
Policy and Charging Control (PCC) over S9 reference point; Policy and Charging Control (PCC) over S9 reference point;
Stage 3 (Release 8)", Stage 3 (Release 8)",
http://www.3gpp.org/ftp/Specs/html-info/29215.htm. <http://www.3gpp.org/ftp/Specs/html-info/29215.htm>.
[TS29.272] [TS29.272]
3rd Generation Partnership Project, "3GPP TS 29.272; 3rd Generation Partnership Project, "3GPP TS 29.272;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
Evolved Packet System; Mobility Management Entity (MME) Evolved Packet System; Mobility Management Entity (MME)
and Serving GPRS Support Node (SGSN) Related Interfaces and Serving GPRS Support Node (SGSN) Related Interfaces
Based on Diameter Protocol (Release 8)", Based on Diameter Protocol (Release 8)",
http://www.3gpp.org/ftp/Specs/html-info/29272.htm. <http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.
[TS29.273] [TS29.273]
3rd Generation Partnership Project, "3GPP TS 29.273; 3rd Generation Partnership Project, "3GPP TS 29.273;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
Evolved Packet System; 3GPP EPS AAA interfaces (Release Evolved Packet System; 3GPP EPS AAA interfaces (Release
8)", http://www.3gpp.org/ftp/Specs/html-info/29273.htm. 8)", <http://www.3gpp.org/ftp/Specs/html-info/29273.htm>.
[WiMAX] WiMAX Forum, "WiMAX Release 1.5", http://
www.wimaxforum.org/resources/documents/technical/T33.
11.2. Informative References
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer [WiMAX] WiMAX Forum, "WiMAX Release 1.5", <http://
(NAPTR) DNS Resource Record", RFC 2915, September 2000. www.wimaxforum.org/resources/documents/technical/T33>.
Authors' Addresses Authors' Addresses
Mark Jones Mark Jones
Bridgewater Systems Bridgewater Systems
Email: mark@azu.ca Email: mark@azu.ca
Jouni Korhonen Jouni Korhonen
Nokia Siemens Networks Nokia Siemens Networks
 End of changes. 15 change blocks. 
44 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/