idnits 2.17.1 draft-liu-aaa-diameter-session-mobility-00.txt: -(329): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-liu-aaa-diameter-session-mobility-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-liu-aaa-diameter-session-mobility-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-liu-aaa-diameter-session-mobility-', but the file name used is 'draft-liu-aaa-diameter-session-mobility-00' == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 463 has weird spacing: '...eipt of such ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 2003) is 7713 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 724, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-aaa-diameter is -16, but you're referring to -17. -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-13 Summary: 3 errors (**), 1 flaw (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AAA Working Group Qing Liu 2 INTERNET-DRAFT Yanqun Le 3 Nokia 5 Expires: August 2003 February 2003 7 Diameter User Session Mobility Application 9 Status of this memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 A mobile node will change its access router frequently during a 33 Diameter session and the relevant AAA parameters may also be 34 transferred between the access routers. However, the home AAA server 35 does not know the movement of the mobile node before the mobile node 36 re-authenticates, and a request from the home AAA server will always 37 be forwarded to the former realm. Therefore, an efficient way is 38 needed to forward the request to the new access router. 40 Table of Contents 42 1. Introduction....................................................2 43 1.1 Requirements language.........................................2 44 1.2 Terminology...................................................3 45 2. Description of the Protocol......................................4 46 2.1 General Requirements..........................................4 47 2.2 Session Mobility Scenarios....................................4 48 2.2.1 Session update scenarios..................................4 49 2.2.2 Diameter message redirection scenario.....................9 50 2.2.3 Race scenario............................................10 51 2.3 Diameter Nodes Operations....................................10 52 2.3.1 AR Operation.............................................10 53 2.3.2 AAAL Operation...........................................10 54 2.3.3 AAAL operation in the race scenario......................11 55 2.4 Advertising Application support..............................12 56 3. Command-Code Values.............................................12 57 3.1 Session-Update-Request.......................................12 58 3.2 Session-Update-Answer........................................13 59 4. Result-Code AVP Values..........................................14 60 5. Mandatory AVPs..................................................14 61 5.1 Anchor-AAA-Server AVP........................................14 62 5.2 Serving-AAA-Server AVP.......................................14 63 5.3 Session-Update-Vector AVP....................................14 64 5.4 Session-Info AVP.............................................14 65 6. AVP Table.......................................................15 66 7. IANA Considerations.............................................15 67 8. Security Considerations.........................................15 68 9. References......................................................15 69 10. Acknowledgements...............................................15 70 11. Author's Addresses.............................................15 71 12. Intellectual Property Rights...................................16 72 13. Full Copyright Statement.......................................16 73 14. Expiration Date................................................16 75 1. Introduction 77 When a mobile node (MN) wants to use resource, its access router 78 (AR) will initiate an authentication and/or authorization request 79 and set up a Diameter session between the AR and the home AAA server 80 (AAAH) which will last until session timeout or being stopped by 81 termination request from the access router. When a MN moves during a 82 session and also the relevant AAA parameters are transferred between 83 these ARs [3], the Diameter session SHOULD be updated, because the 84 AAAH does not know the movement of the MN before the MN re- 85 authenticates and a request from the AAAH (e.g. Abort-Session- 86 Request or Re-Auth-Request, etc.) will always be forwarded to the 87 former realm where the initial auth request is originated. 89 This Diameter application introduces an anchor AAAL, which will 90 redirect the request from the home domain to the new AR. Two new 91 messages (Session-Update-Request and Session-Update-Answer) are 92 defined for the new AR to update the session information maintained 93 in the anchor AAAL or the old AAAL. In the meantime, the other 94 relevant user AAA information will be transferred to the new AAAL. 96 1.1 Requirements language 98 In this document, the key words "MAY", "MUST", "MUST NOT", 99 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 100 interpreted as described in [2]. 102 1.2 Terminology 104 This section presents a few terms used throughout the document. 106 oAR old AR, the old access router, having provided access to the 107 mobile node previously. 109 nAR new AR, the new access router, providing access to the mobile 110 node currently. 112 aAAAL anchor AAAL, the local AAA server, where the mobile node has 113 initially established its Diameter session with its home AAA server 114 before the its handover, and which may re-direct the received AAA 115 messages from the home domain to the new access router. 117 oAAAL old AAAL, the local AAA server, having provided AAA service 118 to the mobile node previously. 119 nAAAL new AAAL, the local AAA server, providing AAA service to the 120 mobile node currently. 122 downstream node The next hop AAA node which the related AAA message 123 aims to. 125 session route The logical route between AR and the MN's home 126 domain AAA server, including all the peer connections within all the 127 related diameter nodes. 129 +------+ 130 | AAAH | 131 +------+ 132 | 133 ... 134 | 135 +------+ +------+ +------+ 136 | aAAAL|-----| oAAAL|-----| nAAAL| 137 +------+ +------+ +------+ 138 | | | 139 +------+ +------+ +------+ 140 | AR | | oAR | | nAR | 141 +------+ +------+ +------+ 142 ^ 143 | 144 v 145 movement +------+ 146 --------> | MN | 147 +------+ 149 Figure 1: MN handover 151 2. Description of the Protocol 153 2.1 General Requirements 155 Here are several requirements: 157 1. Each AR knows its local AAA server by some means. 159 2. The values of oAAAL and aAAAL should be available for the nAAAL 160 after handover. 162 3. The request from the AAAH SHOULD always go through the aAAAL. 164 4. An AAAL should maintain the downstream node for an active 165 session, for example, [Session Id, downstream node, Session 166 timeout]. Any other user AAA information maintained in AAAL can be 167 transferred to the nAAAL. 169 2.2 Session Mobility Scenarios 171 Diameter user session need to updated when MN changes its access 172 router, and those diameter messages heading for MN's current access 173 router need to be redirected. Therefore, three scenarios are 174 proposed. 176 2.2.1 Session update scenarios 178 When the MN changed its access router from oAR to nAR, the session 179 route should be updated immediately after handover. 181 If the MN changes its AR between two AAALs, upon the arrival of MN's 182 AAA parameters, the nAR will send Session-Update-Request (SUR) 183 message through the nAAAL, optionally the oAAAL, to the aAAAL, so 184 that the downstream node information maintained in the aAAAL can be 185 updated from the oAAAL to the nAAAL. In the meantime, the other 186 relevant user AAA information MAY be transferred to the nAAAL by 187 Session-Update-Answer message. If the MN changes its AR inside one 188 AAAL, the new AR just sends Session-Update-Request message to the 189 current AAAL, informing it to update the downstream node information 190 from the oAR to the nAR. 192 There are several scenarios where handover between two ARs may 193 happen: 195 1) Inside one AAAL, whether it is aAAAL or not 197 +------+ 198 | AAAH | 199 +------+ 200 | SessionId: foo 202 ... Downstream node: nAR 203 | ... 204 +------+ +------+ 205 | aAAAL|-----------| nAAAL| 206 +------+ +------+ 207 | / \ 208 +------+ +------+ +------+ 209 | AR | | oAR | | nAR | 210 +------+ +------+ +------+ 211 ^ 212 | 213 v 214 movement +------+ 215 --------> | MN | 216 +------+ 218 Figure 2: Session Update inside one AAAL 220 - oAR will release session information after successful handover; 222 - nAR will send Session-Update-Request (SUR) to the AAAL to update 223 the downstream node to nAR. 225 2) From aAAAL (or oAAAL) to nAAAL 227 +------+ aAAAL 228 | AAAH | SessionId: foo 229 +------+ Downstream node:nAAAL 230 | 231 ... nAAAL 232 | SessionId: foo 233 +------+ +------+ +------+Downstream node: nAR 234 | aAAAL|-----| oAAAL|-----| nAAAL| ... 235 +------+ +------+ +------+ 236 | | | 237 +------+ +------+ +------+ 238 | AR | | oAR | | nAR | 239 +------+ +------+ +------+ 240 ^ 241 | 242 v 243 movement +------+ 244 --------> | MN | 245 +------+ 247 Figure 3: Session Update between two AAALs 249 - oAR will release session information after successful handover; 250 - nAR will send SUR with Destination-Host AVP set to oAAAL, Anchor- 251 AAA-Server AVP set to aAAAL and Serving-AAA-Server AVP set to nAAAL. 252 The request of the command is used to update the downstream node in 253 aAAAL and its answer is to transfer the user AAA information from 254 aAAAL or oAAAL to the nAAAL. 256 - When SUR passes through nAAAL, the nAAAL will update its 257 downstream node to the host in Origin-Host AVP, besides forwarding 258 the message; 260 - When oAAAL receives SUR, it compares local host with the value of 261 Anchor-AAA-Server AVP. If they are different, the oAAAL should 262 replace the Destination-Host AVP value with that of Anchor-AAA- 263 Server AVP and send the request out; 265 - When aAAAL receives SUR, it should update the downstream node to 266 the value of Serving-AAA-Server AVP and send back Session-Update- 267 Answer message. In addition, if there is user AAA information 268 maintained in the aAAAL, this information is encoded into a Session- 269 Info AVP included as part of the SUA message. Once the AAA 270 information is transferred, AAA server doesn�t need to maintain it 271 any longer; 273 - If, otherwise, the user AAA information is maintained in oAAAL, 274 the information will be inserted into SUA message as a Session-Info 275 AVP when the message is forwarded from oAAAL to nAAAL; 277 - In the path of the SUA, if some AAAL detects that its local host 278 name equals to the value of Serving-AAA-Server AVP in the message 279 (i.e. it is nAAAL), it will extract the Session-Info AVP and save 280 the user AAA information locally. 282 3) From oAAAL to aAAAL, i.e. MN returns to the original sub-domain 284 +------+ 285 | AAAH | 286 +------+ aAAAL 287 | SessionId: foo 288 ... Downstream node: nAR 289 | ... 290 +------+ +------+ 291 | aAAAL|-----------| oAAAL| 292 +------+ +------+ 293 | | 294 +------+ +------+ 295 | AR | | oAR | 296 +------+ +------+ 297 ^ 298 | 299 v 301 +------+ movement 302 | MN | <-------- 303 +------+ 305 Figure 4: MN returns to original sub-domain 307 - oAR will release session information after successful handover; 309 - nAR will send SUR with Destination-Host set to oAAAL, Anchor-AAA- 310 Server set to aAAAL and Serving-AAA-Server set to nAAAL; 312 - When SUR passes through nAAAL, the nAAAL will update its 313 downstream node to the Origin-Host besides forwarding the message. 314 If it discovers it is aAAAL, it must add Session-Update-Vector with 315 Passed-Anchor-AAAL flag set to one before forwarding, in order to 316 inform oAAAL that the message has passed aAAAL; 318 - On receipt of SUR, since Passed-Anchor-AAAL flag is one in the 319 message, oAAAL encodes the maintained user AAA into a Session-Info 320 AVP included as part of the Session-Update-Answer message to be sent 321 back; 323 - In the path of the SUA, if some AAAL detects that its local host 324 name equals to the value of Serving-AAA-Server AVP in the message 325 (i.e. it is nAAAL), it will extract the Session-Info AVP and save 326 the user AAA information locally. 328 4) From oAAAL to nAAAL, also aAAAL is in the middle of them. But AR 329 doesn�t know the route to oAAAL passes aAAAL, so Destination-Host of 330 SUR still points to oAAAL 332 +------+ aAAAL 333 | AAAH | SessionId: foo 334 +------+ Downstream node:nAAAL 335 | 336 ... nAAAL 337 | SessionId: foo 338 +------+ +------+ +------+Downstream node: nAR 339 | oAAAL|-----| aAAAL|-----| nAAAL| ... 340 +------+ +------+ +------+ 341 | | | 342 +------+ +------+ +------+ 343 | oAR | | AR | | nAR | 344 +------+ +------+ +------+ 345 ^ 346 | 347 v 348 movement +------+ 349 ---------------> | MN | 350 +------+ 352 Figure 5: Session Update between two AAALs bypass aAAAL 354 - oAR will release session information after successful handover; 356 - nAR will send SUR with Destination-Host set to oAAAL, Anchor-AAA- 357 Server set to aAAAL and Serving-AAA-Server set to nAAAL; 359 - When SUR passes through nAAAL, the nAAAL will update its 360 downstream node to the host in the Origin-Host AVP, besides 361 forwarding the message; 363 - When SUR passes through aAAAL, the aAAAL discovers that its local 364 host doesn�t equal to the value of Serving-AAA-Server, so it will 365 update its downstream node to the Serving-AAA-Server. Also, it must 366 add Session-Update-Vector with Passed-Anchor-AAAL flag set to one 367 before forwarding the message; 369 - On receipt of SUR, since Passed-Anchor-AAAL flag is one in the 370 message, oAAAL encodes the maintained user AAA into a Session-Info 371 AVP included as part of the Session-Update-Answer message to be sent 372 back; 374 - In the path of the SUA, if some AAAL detects that its local host 375 name equals to the value of Serving-AAA-Server AVP in the message 376 (i.e. it is nAAAL), it will extract the Session-Info AVP and save 377 the user AAA information locally. 379 5) MN returns to its home domain 381 +------+ +------+ +------+ 382 | aAAAL|-----| oAAAL|-----| AAAH | 383 +------+ +------+ +------+ 384 | | | 385 +------+ +------+ +------+ 386 | AR | | oAR | | nAR | 387 +------+ +------+ +------+ 388 ^ 389 | 390 v 391 movement +------+ 392 --------> | MN | 393 +------+ 395 Figure 6: MN returns to its home domain 397 - oAR will release session information after successful handover; 399 - nAR will send SUR with Destination-Host set to oAAAL, Anchor-AAA- 400 Server set to aAAAL and Serving-AAA-Server set to nAAAL (i.e. AAAH); 401 - When SUR passes through nAAAL, the AAAH will add Session-Update- 402 Vector AVP with Passed-AAAH flag set to one, in order to inform 403 aAAAL that the message has passed AAAH; 405 - When oAAAL receives SUR, it compares local host with the value of 406 Anchor-AAA-Server AVP. If they are different, the oAAAL should 407 replace the Destination-Host AVP value with that of Anchor-AAA- 408 Server AVP and send the request out; 410 - When aAAAL receives SUR, as the Passed-AAAH flag is one, whether 411 to transfer the maintained user AAA information is application 412 specific. After SUA is sent, it will free the relevant information 413 of the session; 415 - If the user AAA information is maintained in oAAAL, whether to 416 transfer the maintained user AAA information is application specific 417 too; 419 2.2.2 Diameter message redirection scenario 421 When a diameter message is heading for the MN's access router, it's 422 destination host and even destination domain should be updated if 423 the MN have moved away from its original access router. 425 There are two scenarios where AR will re-authenticate or terminate 426 session caused by RAR or ASR from AAAH separately: 428 1. When MN is still in aAAAL, the request will be forwarded 429 according to the downstream node value maintained in the AAAL. 431 2. When MN is in AAAL other than aAAAL 433 - The request will be forwarded according to the downstream node; 435 - The user AAA information in aAAAL can be released after Re-Auth- 436 Answer is forwarded or Abort-Session-Answer with DIAMETER_SUCCESS 437 Result-Code is forwarded. 439 - The re-auth or STR should be delivered as that defined in Diameter 440 base protocol. 442 If nAR re-initiates auth-request through a new AAAL, it becomes 443 aAAAL for this extended session. The downstream node in the old 444 aAAAL will be released by session timeout. 446 If the session termination is initiated by AR, it should forward STR 447 to AAAH as that defined in the Diameter base protocol. The user AAA 448 information in aAAAL, if it is not the current AAAL, will be 449 released by session timeout. 451 If AAAH receives a message from nAAAL that is different from aAAAL, 452 it will update its pointer from aAAAL to nAAAL. 454 2.2.3 Race scenario 456 When a diameter message is heading for the MN's access router, and 457 the MN's is changing its access router, the diameter message would 458 be discarded if it reached the oAR when MN had already changed to 459 the nAR. Therefore, when oAR receives a request (e.g. RAR or ASR) 460 from AAAL (possibly originally from AAAH) for a session that has 461 moved to nAR. This happens when SUR message has not yet been 462 processed. oAR will answer with Result-Code set to 463 DIAMETER_UNKNOWN_SESSION_ID. Upon receipt of such an answer, oAAAL 464 will wait for SUR message with the matching Session-Id AVP, and 465 until then oAAAL will either forward the answer to upstream AAAL or 466 re-send the request (retrieved from the pending queue) to the new 467 downstream AR (nAR) or AAAL. 469 2.3 Diameter Nodes Operations 471 2.3.1 AR Operation 473 After successful handover, oAR will release session information and 474 nAR will send SUR to oAAAL with Destination-Host set to oAAAL. If 475 oAAAL doesn�t equal to any of its local AAA servers, the request 476 message should also include Anchor-AAA-Server AVP with the value of 477 the transferred aAAAL and Serving-AAA-Server AVP with the value of 478 the nAAAL. 480 2.3.2 AAAL Operation 482 When AAAL receives SUR (Destination-Host equals to local host), 483 firstly it will check whether SUR includes Anchor-AAA-Server AVP. If 484 none exists, it means handover is inside the AAAL and then the AAAL 485 only need to update its downstream node from oAR to nAR. Otherwise, 486 it compares local host with the value of Anchor-AAA-Server. If they 487 are different, this AAAL is not aAAAL, and should decide whether to 488 go on forwarding the SUR by checking the Passed-Anchor-AAAL flag of 489 Session-Update-Vector AVP. If the flat is one (it means the SUR has 490 passed aAAAL), the AAAL send back Session-Update-Answer message with 491 Session-Info AVP including the maintained AAA information; 492 otherwise, it replaces the Destination-Host value with that of 493 Anchor-AAA-Server, and continues to send the request. If local host 494 matches the value of Anchor-AAA-Server AVP, besides updating the 495 downstream node to the Serving-AAA-Server, it will send back SUA 496 message, with Session-Info AVP if user AAA information for the 497 session is still maintained. 499 If SUR passes through AAAL (Destination-Host doesn�t equal to local 500 host), it compares local host with Serving-AAA-Server and Anchor- 501 AAA-Server. If local host matches Serving-AAA-Server, the AAAL will 502 update its downstream node to the value of Origin-Host. If local 503 host matches Anchor-AAA-Server, it must add Session-Update-Vector 504 with Passed-Anchor-AAAL flag set to one; in addition, if it doesn�t 505 match Serving-AAA-Server, the AAAL will update its downstream node 506 to the value of Serving-AAA-Server. 508 If AAAL receives SUA and also maintains the user AAA information of 509 the session, the generated SUA should include Session-Info AVP with 510 the user AAA information and be sent back to AR. If SUA passes 511 through nAAAL, the user AAA information should be exacted from the 512 message and saved locally. 514 When AAAL receives RAR or ASR from the home domain of the MN or from 515 aAAAL, it should continue to forward the message after replacing the 516 value of Destination-Host AVP with its saved downstream node of this 517 session. Upon the receipt of the answer for the request, it will 518 release the maintained AAA information after the answer is sent out. 519 When session timeout, AAAL should release the downstream node (if 520 exists). 522 2.3.3 AAAL operation in the race scenario 524 If AAAL receives an answer with the Result-Code AVP set to 525 DIAMETER_UNKNOWN_SESSION_ID from a downstream AR (oAR) or AAAL, it 526 will wait for SUR message with the matching Session-Id AVP for a 527 certain period of time, meanwhile holding the answer. After the 528 matching SUR has been received and neither of the flags of Session- 529 Update-Vector AVP is set, AAAL will re-send the request to the new 530 downstream AR (nAR) or AAAL and free the answer, Otherwise it will 531 forward this answer. 532 +------+ 533 | AAAH | 534 +------+ 535 | 536 ... 537 | 538 +------+ 539 | aAAAL| 540 +------+ 541 / \ 542 +------+ +------+ 543 | oAR | | nAR | 544 +------+ +------+ 545 ^ 546 | 547 v 548 movement +------+ 549 -------->| MN | 550 +------+ 552 Figure 7: AAAL in race scenario under the same AAAL 554 +------+ 555 | AAAH | 556 +------+ 557 | 558 ... 559 | 560 +------+ +------+ 561 | aAAAL|-----------| oAAAL| 562 +------+ +------+ 563 | | 564 +------+ +------+ 565 | nAR | | oAR | 566 +------+ +------+ 567 ^ 568 | 569 v 570 +------+ movement 571 | MN | <-------- 572 +------+ 574 Figure 8: AAAL in race scenario (returns to aAAAL) 576 2.4 Advertising Application support 578 Diameter nodes conforming to this specification MAY advertise 579 support by including the value of XXXX in the Auth-Application-Id or 580 the Acct-Application-Id AVP of the Capabilities-Exchange-Request and 581 Capabilities-Exchange-Answer command [1]. 583 3. Command-Code Values 585 This section defines Command-Code [1] values that MUST be supported 586 by all Diameter implementations conforming to this specification. 587 The following Command Codes are defined in this specification: 589 Command-Name Abbreviation Code Section 590 ----------------------------------------------------------- 591 Session-Update-Request SUR TBD 3.1 592 Session-Update-Answer SUA TBD 3.2 594 3.1 Session-Update-Request 596 The Session-Update-Request (SUR), indicated by the Command-Code set 597 to TBD and the Command Flags' 'R' bit set, is sent by the access 598 device or the Diameter Client to inform relevant Diameter Server 599 that an authenticated and/or authorized session is being updated. 601 Message Format 603 ::= < Diameter Header: TBD, REQ, PXY > 604 < Session-Id > 605 { Origin-Host } 606 { Origin-Realm } 607 { Destination-Host} 608 { Destination-Realm } 609 { Auth-Application-Id } 610 [ User-Name ] 611 [ Anchor-AAA-Server ] 612 [ Serving-AAA-Server ] 613 [ Session-Update-Vector ] 614 * [ Class ] 615 [ Origin-State-Id ] 616 * [ AVP ] 617 * [ Proxy-Info ] 618 * [ Route-Record ] 620 3.2 Session-Update-Answer 622 The Session-Update-Answer (SUA), indicated by the Command-Code set 623 to TBD and the message flags' 'R' bit clear, is sent by the Diameter 624 Server to acknowledge the notification that the session has been 625 updated. The Result-Code AVP MUST be present, and MAY contain an 626 indication that an error occurred while servicing the SUR. 628 Message Format 630 ::= < Diameter Header: TBD, PXY > 631 < Session-Id > 632 { Result-Code } 633 { Origin-Host } 634 { Origin-Realm } 635 [ User-Name ] 636 [ Session-Info] 637 [ Serving-AAA-Server ] 638 * [ Class ] 639 [ Error-Message ] 640 [ Error-Reporting-Host ] 641 * [ Failed-AVP ] 642 [ Origin-State-Id ] 643 * [ Redirect-Host ] 644 [ Redirect-Host-Usase ] 645 [ Redirect-Max-Cache-Time ] 646 * [ AVP ] 647 * [ Proxy-Info ] 649 4. Result-Code AVP Values 651 5. Mandatory AVPs 653 The following table describes the Diameter AVPs defined in the 654 Mobile IP application, their AVP Code values, types, possible flag 655 values and whether the AVP MAY be encrypted. 657 +---------------------+ 658 | AVP Flag rules | 659 |----+-----+----+-----|----+ 660 AVP Section | | |SHLD| MUST|MAY | 661 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 662 ----------------------------------------|----+-----+----+-----|----| 663 Anchor-AAA- TBD 5.1 DiamIdent | M | P | | V | Y | 664 Server | | | | | | 665 Serving-AAA- TBD 5.2 DiamIdent | M | P | | V | Y | 666 Server | | | | | | 667 Session-Info TBD 5.4 Grouped | M | P | | V | Y | 668 Session-Update- TBD 5.3 Unsigned32 | M | P | | V | Y | 669 Vector 671 5.1 Anchor-AAA-Server AVP 673 The Anchor-AAA-Server AVP (AVP Code TBD) is of type DiameterIdentity 674 and contains the identity of the anchor AAA server (i.e. aAAAL) in 675 the foreign network. 677 5.2 Serving-AAA-Server AVP 679 The Serving-AAA-Server AVP (AVP Code TBD) is of type 680 DiameterIdentity and contains the identity of the serving AAA server 681 (i.e. nAAAL) in the foreign network. 683 5.3 Session-Update-Vector AVP 685 The Session-Update-Vector AVP (AVP Code TBD) is of type Unsigned32 686 and is added with flag values set by the aAAAL or AAAH. 687 Flag values currently defined include: 688 1 Passed-Anchor-AAAL 689 2 Passed-AAAH 691 5.4 Session-Info AVP 693 The Session-Info AVP (AVP Code TBD) is of type Grouped and contains 694 the user AAA information (except Session-Id) maintained in the AAAL. 695 The possible values of this AVP are TBD. 697 AVP Format 698 ::= < AVP Header: TBD > 699 1* {AVP} 701 6. AVP Table 703 TBD 705 7. IANA Considerations 707 8. Security Considerations 709 TBD. 711 9. References 713 [1] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, "Diame- 714 ter Base Protocol", draft-ietf-aaa-diameter-17.txt, IETF work 715 in progress, December 2002. 717 [2] S. Bradner. "Key words for use in RFCs to Indicate Requirement 718 Levels". BCP 14, RFC 2119, March 1997. 720 [3] D. Forsberg, R. Koodli, C. Perkins, "Context Relocation of AAA 721 Parameters in IP Networks", draft-forsberg-seamoby-aaa- 722 relocate-00.doc, work in progress. 724 [4] P. Calhoun, T. Johansson, C. Perkins, "Diameter Mobile IPv4 725 Application", draft-ietf-aaa-diameter-mobileip-13.txt, work in 726 progress, October 2002. 728 10. Acknowledgements 730 11. Author's Addresses 732 Qing Liu 733 Nokia Research Center 734 Nokia House 1, No.11, He Ping Li Dong Jie 735 Beijing, 100013 736 P.R.China 738 E-mail: qing.roger.liu@nokia.com 739 Yanqun Le 740 Nokia Research Center 741 Nokia House 1, No.11, He Ping Li Dong Jie 742 Beijing, 100013 743 P.R.China 745 E-mail: yanqun.le@nokia.com 746 Dan Forsberg 747 Nokia Research Center, 748 P.O. Box 407 749 FIN-00045 Nokia GroupI 750 E-mail: dan.forsberg@nokia.com 752 12. Intellectual Property Rights 754 The IETF has been notified of intellectual property rights claimed 755 in regard to some or all of the specification contained in this 756 document. For more information consult the online list of claimed 757 rights at http://www.ietf.org/ipr. 759 13. Full Copyright Statement 761 Copyright (C) The Internet Society (2001). All Rights Reserved. 762 This document and translations of it may be copied and furnished to 763 others, and derivative works that comment on or otherwise explain it 764 or assist in its implementation may be prepared, copied, published 765 and distributed, in whole or in part, without restriction of any 766 kind, provided that the above copyright notice and this paragraph 767 are included on all such copies and derivative works. However, this 768 docu-ment itself may not be modified in any way, such as by removing 769 the copyright notice or references to the Internet Society or other 770 Internet organizations, except as needed for the purpose of develop- 771 ing Internet standards in which case the procedures for copyrights 772 defined in the Internet Standards process must be followed, or as 773 required to translate it into languages other than English. The lim- 774 ited permissions granted above are perpetual and will not be revoked 775 by the Internet Society or its successors or assigns. This document 776 and the information contained herein is provided on an "AS IS" basis 777 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 778 DIS-CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 779 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 780 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 781 OR FITNESS FOR A PARTICULAR PURPOSE. 783 14. Expiration Date 785 This memo is filed as and expires in August 2003.