One document matched: draft-tsou-dime-capabilities-update-statement-00.txt
DIME T. TSOU
Internet-Draft Huawei
Intended status: Informational July 28, 2008
Expires: January 29, 2009
Capabilities Update Problem Statement
draft-tsou-dime-capabilities-update-statement-00
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 January 29, 2009.
TSOU Expires January 29, 2009 [Page 1]
Internet-Draft Capabilities Update Problem Statement July 2008
Abstract
This specification clarifies "Capabilities Update" in OPEN state
defined in RFC 3588bis. Capabilities update in OPEN state can reuse
commands CER/CEA commands for re-negotiation between Diameter peers
when one of them changes its capabilities.It is a very important
function in Diameter.
However, RFC 3588 has defined a mechanism of containing capabilities
list both in CER and CEA commands and the peer should update its
local database whenever it receives CER/CEA. This makes the process
complex and redundant when they are used in OPEN state. So this
draft proposes a simpler solution based on CER/CEA commands to deal
with this problem.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Solution Description . . . . . . . . . . . . . . . . . . . 9
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Changes to ABNF . . . . . . . . . . . . . . . . . . . . . 12
4.4. Compatibility Consideration . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
TSOU Expires January 29, 2009 [Page 2]
Internet-Draft Capabilities Update Problem Statement July 2008
1. Introduction
This specification clarifies "Capabilities Update" in OPEN state
defined in RFC 3588bis. It specifies reusing CER/CEA commands for
capabilities re-negotiation between Diameter peers when one of them
changes its capabilities after establishing connection.
CER/CEA mechanism is formerly used in initialization phase when two
Diameter peers establish a transport connection and in this case no
one ever knows the capabilities of its peers. RFC 3588 defines a
mechanism of containing capabilities list both in CER and CEA
commands and the peer should update its local database whenever it
receives CER/CEA.
However, when CER/CEA are used in OPEN state, the above CER/CEA
solution will make the exchange process complex and redundant because
in this case diameter peer has cached the capabilities of its peers
during initialization phase. If the receiver of CER does not change
its capabilities, the sender of CER can get its peer's capabilities
from cache memory and it doesn't need to process CEA (e.g. update its
cache memory or routing tables). On the other hand, if the receiver
of CER does change its capabilities, it also doesn't need to include
the capabilities list in CEA because it will initial a new CER as
soon as possible. So based on current solution, redundant data is
transmitted and needless reactions are implemented in diameter peers.
This specification proposes the issues describing the redundancy of
Capabilities Update in OPEN state defined in RFC 3588bis, and in the
meantime, it proposes a simplified solution based on CER/CEA commands
for Capabilities Update. This solution is fully backwards compatible
with the RFC 3588 Diameter Base Protocol.
TSOU Expires January 29, 2009 [Page 3]
Internet-Draft Capabilities Update Problem Statement July 2008
2. Terminology and Abbreviations
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 [RFC2119].
TSOU Expires January 29, 2009 [Page 4]
Internet-Draft Capabilities Update Problem Statement July 2008
3. Problem Overview
RFC 3588bis section 5.6.5 defines the Capabilities Update in OPEN
state in details. It specifies reusing CER/CEA for re-negotiation
between diameter peers.
A Diameter node must initiate peer capabilities update by sending a
Capabilities-Exchange-Req (CER) to all its peers which supports peer
capabilities update and is in OPEN state. The receiver of CER in
OPEN state must process and reply to the CER as a described in RFC
3588bis section 5.3. The CEA which the receiver sends MUST contain
its latest capabilities. Peers that successfully process the peer
capabilities update SHOULD also update their routing tables to
reflect the change.
In order to clarify the problems, we can analyze the message exchange
based on the above solution in the following key scenarios:
Scenario 1: The receiver of CER doesn't change its capabilities when
a CER arrives.
Scenario 2: The receiver of CER does change its capabilities when a
CER arrives.
Figure 1 provides an example of message exchange in scenario 1. In
Open State, Node A changes its capabilities and it initializes a CER
for Node B. Node B does not change its capabilities when it receives
the CER from node A.
Node A Node B
| |
| |
| |
| |
+-----------------+ +-------------------+
| Node A supports | | Node B supports |
| application(a,b)| | application(a,c,d)|
+-----------------+ +-------------------+
| |
| |
------------------------- In Open State ---------------------------
| |
+-----------------------+ +----------------------------+
|Capabilities of Node A | | Capabilities of Node B |
|change and it supports | | don't change and it still |
|application(a,b,c) | | supports application(a,c,d)|
+-----------------------+ +----------------------------+
| CER(a,b,c) |
TSOU Expires January 29, 2009 [Page 5]
Internet-Draft Capabilities Update Problem Statement July 2008
|------------------------------------>|
| +-----------------+
| |Determine common |
| |application(a,c) |
| +-----------------+
| |
| |
| +-----------------------+
| | Cache capabilities of |
| | Node A and update |
| | routing tables |
| +-----------------------+
| |
| CEA(Result-Code=DIAMETER_SUCCESS, |
| a,c,d) |
|<------------------------------------|
+-----------------+ |
|Determine common | |
|applications(a,c)| |
+-----------------+ |
| |
| |
+-----------------------+ |
| Cache capabilities of | |
| Node B and update | |
| routing table | |
+----------- -----------+ |
| |
| |
| |
Figure1: Capabilities Update in scenario 1
From Figure 1, capabilities of node B haven't been updated at that
time. B will return CEA containing the same capabilities as that
during initialization phase and have been cached by node A. So node A
will process the CEA repeatedly.
Figure 2 provides an example of message exchange in scenario 2. In
Open State, node A changes its capabilities and it initializes a CER
for node B. Node B also changes its capabilities at the time it
receives CER. This case rarely happens but it indeed occurs
sometime.
Node A Node B
| |
TSOU Expires January 29, 2009 [Page 6]
Internet-Draft Capabilities Update Problem Statement July 2008
| |
+-----------------+ +-------------------+
| Node A supports | | Node B supports |
| application(a,b)| | application(a,c) |
+-----------------+ +-------------------+
| |
| In Open State |
-------------------------------------------------------------
| |
+-----------------------+ +------------------------+
|Capabilities of Node A | |Capabilities of Node B |
|change and it supports | |change and it supports |
|application(a,b,c) | | application(a,c,d) |
+-----------------------+ +------------------------+
| CER(a,b,c) |
|-------------------------------------->|
| +-----------------+
| |Determine common |
| |application(a,c) |
| +-----------------+
| |
| +-----------------------+
| | Cache capabilities of |
| | Node A and update |
| | routing tables |
| CER(a,c,d) +-----------------------+
|<--------------------------------------|
+-----------------+ |
|Determine common | |
|applications(a,c)| |
+-----------------+ |
| |
+-----------------------+ |
| Cache capabilities of | |
| Node B and update | |
| routing table | |
+-----------------------+ |
| CEA(Result-Code=DIAMETER_SUCCESS, |
| a,c,d) |
|<--------------------------------------|
+-----------------+ |
|Determine common | |
|application(a,c) | |
+-----------------+ |
| |
+-----------------------+ |
| Cache capabilities of | |
| Node B and update | |
TSOU Expires January 29, 2009 [Page 7]
Internet-Draft Capabilities Update Problem Statement July 2008
| routing tables | |
+-----------------------+ |
| CEA(Result-Code=DIAMETER_SUCCESS, |
| a,b,c) |
|-------------------------------------->|
| +-----------------+
| |Determine common |
| |application(a,c) |
| +-----------------+
| |
| +-----------------------+
| | Cache capabilities of |
| | Node A and update |
| | routing tables |
| +-----------------------+
| |
| |
Figure2: Capabilities Update in scenario 2
From Figure 2, capabilities of node B have been updated at the time
it receives CER from node A. According to current solution, there
will be twice capabilities updates between the same two diameter
nodes with the same capabilities list exchanged. Besides, in each
peer, there will be twice repetitious processes, one for receiving of
CER and one for receiving of CEA.
TSOU Expires January 29, 2009 [Page 8]
Internet-Draft Capabilities Update Problem Statement July 2008
4. Solution Overview
This specification defines a solution for Capabilities Update in OPEN
State based on CER/CEA commands and it is fully backwards compatible
with the RFC 3588 Diameter Base Protocol.
4.1. Solution Description
A Diameter node MUST initiate peer capabilities update by sending a
Capabilities-Exchange-Req (CER) to all its peers which supports peer
capabilities update and is in OPEN state. The receiver of CER in
OPEN state MUST process and reply to the CER. The CEA which the
receiver sends SHOULD NOT contain its capabilities list. Note that
the receivers of CER which successfully process the peer capabilities
update SHOULD also update their routing tables to reflect the change.
The receiver of the CEA, with a Result-Code AVP indicating
DIAMETER_SUCCESS SHOULD not update its storage and continue using
local cached capabilities of its peer until a new CER arrives. The
receiver of the CEA, with a Result-Code AVP other than
DIAMETER_SUCCESS, initiates the transport disconnect. The peer may
periodically attempt to reconnect, as stated in RFC3588bis section
2.1.
Peer capabilities update in the OPEN state SHOULD be limited to the
advertisement of the new list of supported applications and MUST
preclude re-negotiation of security mechanism or other capabilities.
If any capabilities change happens in the node (e.g. change in
security mechanisms), other than a change in the supported
applications, the node SHOULD gracefully terminate (setting the
Disconnect-Cause AVP value to REBOOTING) and re-establish the
diameter connections to all the peers.
4.2. Examples
Figure 3 provides an example of message exchange in scenario 1 with
node A and node B using the new solution:
TSOU Expires January 29, 2009 [Page 9]
Internet-Draft Capabilities Update Problem Statement July 2008
Node A Node B
| |
| |
+-----------------+ +-------------------+
| Node A supports | | Node B supports |
| application(a,b)| | application(a,c,d)|
+-----------------+ +-------------------+
| |
------------------------- In Open State -------------------------
| |
+-----------------------+ +----------------------------+
|Capabilities of Node A | | Capabilities of Node B |
|change and it supports | | don't change and it still |
|application(a,b,c) | | supports application(a,c,d)|
+-----------------------+ +----------------------------+
| CER(a,b,c) |
|------------------------------------>|
| +-----------------+
| |Determine common |
| |application(a,c) |
| +-----------------+
| |
| |
| +-----------------------+
| | Cache capabilities of |
| | Node A and update |
| | routing tables |
| +-----------------------+
| |
| CEA(Result-Code=DIAMETER_SUCCESS) |
|<------------------------------------|
| |
+-----------------+ |
| Contiune using | |
| local cached B's| |
| capabilities | |
+-----------------+ |
| |
Figure3: Capabilities Update in scenario 1
From Figure 3, capabilities of node B haven't been updated at that
time. Node B returns CEA with a result-Code AVP indicating
"DIAMETER_SUCCESS" not containing any capabilities list. In this
way, node A will continue using local cached node B's capabilities.
TSOU Expires January 29, 2009 [Page 10]
Internet-Draft Capabilities Update Problem Statement July 2008
Figure 4 provides an example of message exchange in scenario 2 with
node A and node B using the new solution:
Node A Node B
| |
| |
+-----------------+ +-----------------+
| Node A supports | | Node B supports |
| application(a,b)| | application(a,c)|
+-----------------+ +-----------------+
| |
| |
-------------------- In Open State ---------------------------
| |
+-----------------------+ +------------------------+
|Capabilities of Node A | |Capabilities of Node B |
|change and it supports | |change and it supports |
|application(a,b,c) | | application(a,c,d) |
+-----------------------+ +------------------------+
| CER(a,b,c) |
|------------------------------------->|
| +-----------------+
| |Determine common |
| |application(a,c) |
| +-----------------+
| |
| +-----------------------+
| | Cache capabilities of |
| | Node A and update |
| | routing tables |
| CER(a,c,d) +-----------------------+
|<-------------------------------------|
+-----------------+ |
|Determine common | |
|applications(a,c)| |
+-----------------+ |
| |
+-----------------------+ |
| Cache capabilities of | |
| Node B and update | |
| routing table | |
+-----------------------+ |
| CEA(Result-Code=DIAMETER_SUCCESS) |
|<-------------------------------------|
+-----------------+ |
| Continue using | |
|local cached B's | |
| capabalities | |
TSOU Expires January 29, 2009 [Page 11]
Internet-Draft Capabilities Update Problem Statement July 2008
+-----------------+ |
| |
| CEA(Result-Code=DIAMETER_SUCCESS) |
|-------------------------------------->|
| +-----------------+
| | Continue using |
| |local cached A's |
| | capabalities |
| +-----------------+
| |
| |
Figure4: Capabilities Update in scenario 2
From Figure 4, capabilities of node B have been updated at that time.
According to the new solution, node B will initiate a CER containing
its capabilities list as soon as possible. Node B processes CER sent
from node A and node A also processes CER from node B. Each peer will
continue using local cache capabilities when it receives CEA.
4.3. Changes to ABNF
In order to implement the new solution, a simplified CEA should be
defined in Open State. This simplified CEA should not contains any
capabilities-related AVPs.
The receiver of CEA should continue using local cached capabilities
of its peer identified by Origin-Host and Origin-Realm.
Message format
<CEA> ::= < Diameter Header: 257 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
[ Error-Message ]
[ Failed-AVP ]
* [ AVP ]
4.4. Compatibility Consideration
In the new solution, CER/CEA in Open State is a little different from
that in initialization phase. Considering the need for
compatibility, the states defined in RFC3588bis Section 5.6 "Peer
State Machine" can be used to differentiate the current phase in
order to adopt proper CER/CEA process. For example, if the state
indicates "Open", simplified CEA should be used.
TSOU Expires January 29, 2009 [Page 12]
Internet-Draft Capabilities Update Problem Statement July 2008
5. IANA Considerations
TBD
TSOU Expires January 29, 2009 [Page 13]
Internet-Draft Capabilities Update Problem Statement July 2008
6. Security Considerations
TBD
TSOU Expires January 29, 2009 [Page 14]
Internet-Draft Capabilities Update Problem Statement July 2008
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
7.2. Informative References
[1] V. Fajardo,Ed.,J. Arkko, J. Loughney, G. Zorn, "Diameter Base
Protocol draft-ietf-dime-rfc3588bis-10", January 22, 2008.
TSOU Expires January 29, 2009 [Page 15]
Internet-Draft Capabilities Update Problem Statement July 2008
Author's Address
Tina TSOU
Huawei Technologies
Huawei Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P. R. China
Phone: +86(755)28972352
Email: Tena@huawei.com
TSOU Expires January 29, 2009 [Page 16]
Internet-Draft Capabilities Update Problem Statement July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
TSOU Expires January 29, 2009 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 04:07:34 |