idnits 2.17.1 draft-gopal-enrp-candidate-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 5) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 76 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 12 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 493: '...C 2279). Senders MUST terminate lines ...' RFC 2119 keyword, line 494: '...F, but receivers MUST also interpret C...' RFC 2119 keyword, line 579: '...to this document MUST use ENRP/1.0 for...' RFC 2119 keyword, line 699: '...to this document MUST use ENRP/1.0 for...' RFC 2119 keyword, line 885: '...n. Initial request messages MUST carry...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 112 has weird spacing: '... Server list ...' == Line 170 has weird spacing: '...rmining the r...' == Line 276 has weird spacing: '...tomatic cache...' == Line 277 has weird spacing: '...oes not have...' == Line 278 has weird spacing: '... PE is activ...' == (71 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2001) is 8320 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2026' on line 1742 looks like a reference -- Missing reference section? 'Req' on line 267 looks like a reference -- Missing reference section? 'Arch' on line 194 looks like a reference -- Missing reference section? 'Papoulis' on line 1774 looks like a reference -- Missing reference section? 'Mullender' on line 1778 looks like a reference -- Missing reference section? '2' on line 503 looks like a reference -- Missing reference section? 'RFC2543' on line 1714 looks like a reference -- Missing reference section? 'RFC 2234' on line 1746 looks like a reference -- Missing reference section? 'RFC2616' on line 1756 looks like a reference -- Missing reference section? 'RFC 2617' on line 1760 looks like a reference -- Missing reference section? 'RFC2960' on line 1764 looks like a reference -- Missing reference section? 'ASAP-Draft' on line 1768 looks like a reference -- Missing reference section? 'Rser-Arch' on line 1781 looks like a reference -- Missing reference section? 'Rser-Comp' on line 1785 looks like a reference -- Missing reference section? 'Rser-req' on line 1789 looks like a reference -- Missing reference section? 'Stevens' on line 1797 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ram Gopal.L 2 INTERNET DRAFT Senthil Sengodan 3 Nokia 4 Expires January, 2002 July 10, 2001 6 End Name Resolution Protocol Candidate (ENRP) 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions 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 other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The goal is to develop a Reliable server pooling protocols for the 32 management and operation of server pools supporting highly reliable 33 applications,and for client access mechanisms to a server pool. 35 This document describes the ENRP protocol and details the how it is 36 used in conjunction with ASAP protocol. 38 Table of Contents 40 1. Introduction..............................................3 41 1.1 Terminology...............................................4 42 1.2. Architectural view .......................................5 43 2 Protocol Overview.........................................7 44 2.1 Name Server pool..........................................7 45 2.2 Choosing the Name Server address for registration.........7 46 2.2.1 ENRP Name server Registration............ ...............7 47 2.2.2 Name Server List download.................................8 48 2.2.2.1 Choosing Name Server ID ................................8 50 Ram & Senthil [Page 1] 51 2.2.2.2 Choosing Care Taker Name Server...........................8 52 2.2.2.3 Avoiding NS-ID Collision..................................9 53 2.3 ENRP Name Server and PE list download ...................9 54 2.4 Name Server Updates .....................................9 55 2.4.1 Name Server Status notification..........................10 56 2.4.2. PE Status notification...................................10 57 2.5 NS deRegistration and NS update..........................10 58 2.6 ENRP Health check........................................10 59 3 Message Overview.........................................10 60 4 Request..................................................12 61 4.1 Request-Line.............................................12 62 4.2 Method...................................................12 63 4.2.1 NS-REGISTRATION..........................................13 64 4.2.2 HEARTBEAT................................................13 65 4.2.3 UPDATE...................................................13 66 4.2.4 NS-DOWNLOAD..............................................14 67 4.2.5 PE-DOWNLOAD..............................................14 68 5 Response Header..........................................14 69 5.1 Status-Line..............................................14 70 5.1.2 Status Codes and Reason Phrases..........................15 71 6 Header Field Definitions.................................16 72 6.1 Allow....................................................16 73 6.2 NS-Parameters ...........................................17 74 6.3 Policy...................................................17 75 6.4 Periodic-Update..........................................18 76 6.5 NS-ID....................................................18 77 6.6 Server-Type..............................................18 78 6.7 Transaction-ID...........................................19 79 6.8 Expires..................................................19 80 6.9 Security Related Headers.................................19 81 6.9.1 WWW-Authenticate ........................................19 82 6.9.2 Authorization............................................20 83 6.9.3 Authentication-Info......................................20 84 6.9.4 Encryption...............................................21 85 6.9.5 Require .................................................21 86 6.9.6 Response-Key.............................................21 87 7 Status Code Definitions..................................21 88 7.1 Successful 2xx...........................................21 89 7.1.1 200 OK...................................................21 90 7.2 Request Failure 4xx......................................22 91 7.2.1 400 Bad Request..........................................22 92 7.2.2 401 Unauthorized.........................................23 93 7.2.3 403 Method Not Allowed...................................22 94 7.2.4 404 Not Found............................................23 95 7.2.5 409 Request Entity Too Large.............................23 96 7.3 Server Failure 5xx.......................................23 97 7.3.1 500 Server Internal Error................................23 98 7.3.2 501 Not Implemented......................................23 99 7.3.3 502 Service Unavailable..................................23 100 7.3.5 503 Version Not Supported................................24 101 8. Behavior of Name Server..................................24 102 8.1 NS - Startup and Shutdown interaction message ..........24 103 8.1.1 Registering Entity Resolves the Name Server with 104 which to Register........................................24 105 8.1.2 Joining Name Server needs to be registered with an NS....25. 106 ................................................... 107 8.1.3 Name ServerDe-Registering itself from the Pool.......... 25 108 8.1.4 Download of ASAP/ENRP pool element information on 109 to NS.......................................... 26 110 8.1.4.1 Name ServerRequests list of Name Servers in NS-pool......26 111 8.1.4.2 Response to ENRP-DOWNLOAD message requesting 112 Name Server list ....................................... 26 113 8.1.4.3 NS requests PE list from caretaker NS................... 27 114 8.1.4.4 Response to NS-DOWNLOAD message requesting PE list.......27 115 8.2 Interaction between a pair of NS.........................28 116 8.2.1 NS Updates NS status to PEs and other NS in the NS-Pool..28 117 8.2.1.1 New NS Registration Notification ........................29 118 8.2.1.2 NS Registration Update...................................29 119 8.2.1.3 NS Heart beat Failure or NS de-Registration 120 Notification Update .....................................29 121 8.2.2 Name Server updating an PE Status to all NS .............30 122 8.2.2.1 PE registration notification ............................30 123 8.2.2.2 PE registration update ..................................31 124 8.2.2.3 PE de-registration or interface heartbeat 125 failure notification ....................................31 126 8.2.3 Caretaker NS sends a Heartbeat Request to other NSs in 127 to NS-pool...............................................32 128 8.2.4 NS sends Heartbeat Response to Care-Taker NS.............33 129 8.2.5 NS notifies all other NSs in NS-pool of a change in 130 caretaker NS ................................33 131 9 Security Considerations..................................34 132 9.1 Confidentiality and Privacy: Encryption..................34 133 9.1.1 Application-Level Encryption............... ..........34 134 9.1.2 Lower-Layer Encryption...................................34 135 9.2 Message Integrity and Access Control: Authentication.....34 136 9.2.1 Illustration of Digest Scheme ...........................34 137 A. Implementation Issues....................................35 138 B. Summary of Augmented BNF........................ ........35 139 C. Acknowledgements.........................................35 140 D Author's Contact Address.................................36 141 E Reference................................................36 143 1 Introduction 145 [Req] discusses requirements for the management and operation 146 of reliable server pools which may be needed for certain 147 applications, and for the client access mechanism to a server pool. 148 [Arch] describes an architecture for achieving such reliable server 149 pools.Two protocols - ASAP and ENRP - are proposed within this 150 architecture.In this document, we give a description of the ASAP 151 protocol. 153 1.1. Terminology 155 In addition to the terminology defined in [Req][Arch], the following 156 terms are defined here: 158 Reliability: As stated in [Papoulis], the reliability of a 159 system is defined as the probability that the system functions 160 at a certain time 't'. In mathematical terms, we have 162 R(t) = P{x>t} 164 where R(t) = system reliability 165 P{.} = Probability of occurrence of the specified event 166 x = Random Variable (RV) denoting "time to failure" of a 167 system 168 t = time 170 A typical metric for determining the reliability of 171 a system is the mean time to failure. The larger this value, the 172 more reliable the system is. 174 Availability: As stated in [Mullender], the availability of a 175 system is defined as the probability that the system provides 176 correct service delivery at a certain time 't'. It is a measure 177 of correct service delivery with respect to the alternation of 178 correct and incorrect service, measured by the probability A(t) 179 that the system is ready to provide the service at a point in 180 time t. 182 ENRP Server: Identical to Name Server [Arch][Req] 184 Proxy PE (PPE): Proxy PE refers to a PE which acts on behalf of 185 application servers, specifically legacy application servers. 187 Proxy PU (PPU): Proxy PU refers to a PU which acts on behalf of a 188 user of a server pool, specifically a legacy user of a server 189 pool. 191 Name Server Pool (NS-Pool) : Refers to ENRP Name Server pool 193 Application Server Pool (AS-Pool): This term refers to "Pool" in 194 [Arch], but is introduced here to distinguish from NS-Pool. 196 Care Taker Name Server: Associated with each Name Server there is 197 one care taker Name Server in the same pool and is responsible for 198 health check. 200 Name Server ID: A unique identifier assigned to each Name Server 201 after registration in an NS-Pool. 202 NS Handle: Refers to transport addresses) of a Name Server. 204 Ram & Senthil [Page 4] 205 1.2 Architectural view 207 Figure 1 represents the architectural view of ENRP in a Rserpool. 208 Communication of the different elements in this architecture is as 209 follows: 211 - ENRP Name Server (say NS 1 and NS 2 ) communicates with each 212 other using ENRP protocol. There may be more than one Name Server in 213 a Rserpool. 215 - ENRP Name server uses its ASAP layer to communicate to its PU or 216 PE. 218 - Name Server keeps information regarding legacy servers but does 219 not communicate to them. 221 +---------------------+ +-----------+ +-----------+ 222 | Application Server | |Legacy | |Legacy | 223 | (A1) | |Server (S1)| |Server (S2)| 224 +---------------------+ +-----------+ +-----------+ 225 | ASAP | || || 226 | | +---------------------+ 227 +---------------------+ | ASAP - PPE (A2) | 228 | Transport Layer | +---------------------+ 229 | | | Transport Layer | 230 +---------------------+ +---------------------+ 231 || || 232 || || 233 =//===================//===============================//=== 234 || 235 +---------------------+ || +-------------------+ 236 | Name Server (NS 1) | || | Pool User (P1) | 237 | | || | | 238 +----------+----------+ || | | 239 | ENRP | ASAP | // +-------------------+ 240 +----------+----------+ || | | 241 | Transport Layer | || | ASAP | 242 +----------+----------+ || +-------------------+ 243 || || | Transport Layer | 244 ||=====//=========|| +-------------------+ 245 || || 246 ||=====//======= 247 || 248 +---------------------+ || +--------+ +--------+ 249 | Name Server (NS 2) | || |Legacy | |Legacy | 250 | | || |Client | |Client | 251 +---------------------+ || | (U1) | | (U2) | 252 | ENRP | ASAP | // +--------+ +--------+ 253 +----------+----------+ || || || 254 | Transport Layer | || || || 255 +---------------------+ || +-------------------+ 256 || || | ASAP - PPU (P2) | 257 ||=======//=======|| +-------------------+ 258 || | Transport Layer | 259 || +-------------------+ 260 Ram & Senthil [Page 5] 261 || || 262 ||====//========= 263 // 265 Figure 2: Architectural view of ENRP Name servers 267 Based on the requirements in [Req], some of the functionality that is 268 provided within the protocol are: 270 - The Name Server discovery mechanism does not rely on multicast 271 technologies. Instead, a set of mechanisms are described, any of 272 which may be used. (Refer 2.1) 274 - The use of Expires header for initial registration, registration 275 modification or deletion of PE with Name Server, permits 276 automatic cache invalidation at the PU. This implies that the PU 277 does not have to initiate queries to a PE to determine whether the 278 PE is active, if it already knows that the PE is not active because 279 its registration has expired. 281 - Separate Registration mechanism are provided for Name Server which 282 is different from PE registration. This will form a pool of ENRP 283 Name server in a RSerPool scope. Apart from this each Name Server 284 discovers its care taker server just after the registration 285 process. (Refer Section 2.2.1 ) 287 Some key characteristics of the architecture of Figure 1 are: 289 - It does not assume any underlying transport protocols, and may 290 use UDP, TCP, SCTP, RDP etc. 292 - All communication between any two entities in the Rserpool is 293 secured - it provides confidentiality, data origin authenticity 294 and replay attack prevention. 296 - The protocol does not rely on multicast, and works both in a 297 unicast and multicast environment. 299 - Each ENRP name server keeps all state information about 300 each PE in the AS-Pool and about other Name Servers and 301 this information is always synchronized between them with 302 minimal message exchange. 304 - Use of an ASCII based message exchange (similar to HTTP, SIP) 305 makes the protocol simpler and easy to implement in low- 306 processing device. 308 - Load balancing is provided at three levels: 309 - Across Name Servers for PU Queries 310 - Across PEs for PU Queries 311 - Across Name Servers for PE heartbeat 313 2 Protocol Overview 315 2.1 Name Server Pool 317 A pool of ENRP Name servers cooperate (and are synchronized) with one 318 another using ENRP, and are said to operate within an operational 319 scope. There may be more than one Name server in an operation scope 320 to form Name server pool. i.e. this is needed for availability and 321 all the Name server cooperate and synchronize themselves. The 322 reasons for having a cooperating/synchronized Name Serverpool 323 include: 325 o to handle the case of Name server failures 327 o distribute load among the Name servers: Load sharing on 328 heartbeat monitoring function (of PE) can be done. 329 (a) When an existing Name Server leaves a pool, then the PEs 330 that are handled by this Name Server need to be distributed 331 among the other Name Servers in the pool. Similarly, when a new 332 Name Server enters a pool, one may wish to redistribute the load 333 among the various Name Servers. 335 (b) It is uncertain if load sharing can be done for PU queries 336 to Name servers. PUs cannot know the list of active Name servers 337 in the operational scope. Their only source of info is from the 338 DNS (which may not be up-to-date). A possibility is that the 339 first time a PU contacts a Name server, that server could 340 download a list of then currently active Name servers, so that 341 the PU can use say a RR policy for subsequent queries to Name 342 servers. 344 2.2 Choosing the Name server address for registration 346 The Name Server that wants to be a part of a NS-pool obtains the list 347 of Name servers from the DNS, or possibly some local configuration 348 setting. This list may not be up-to-date, and some entries in the list 349 may not be in the NS-pool, while there may be other Name 350 servers in the pool that are not listed in this entry. The joining Name 351 Server (Say A ) picks one Name server (Say B) (could be arbitrary) 352 and sends its registration to this Name server B. 354 2.2.1 ENRP Name Server Registration 356 The joining Name Server (say A) after choosing the Name server from the 357 list ( Refer Section 2.2 ) sends the NS-REGISTRATION message to the 358 Name server(say B). The Name server does the initial authentication 359 (depending upon the security protocol) and sends back the 360 NS-REGISTRATION response with the appropriate status code. A typical NS- 361 REGISTRATION request contains, Expire time, service policy and other 362 server specific information. 364 2.2.2 Name Server List download 366 After NS-REGISTRATION is completed successfully, the newly joined 367 Name Server (Say A) then requests for the Name server list by sending an 368 NS-DOWNLOAD Request to the Name server with which it completed its 369 registration (Say B) . 371 2.2.2.1 Choosing Name Server ID 373 Requesting Name server after receiving Name Server list, computes the 374 NS-ID (Name Server ID) that it assigns itself, and chooses its 375 Care taker Name Server. 377 The new Name server scans through the all Name server ID's in the list 378 and chooses the NS-ID which is one greater than the highest value in 379 the list. i.e, for example if we have five Name Servers and their NS 380 id are 1,4,5,6 and 15, then the new Name Server that joins the pool 381 will assign itself an NS-ID of 16 and its care taker Name Server will 382 have an NS-ID 15. 384 Name Server NS-ID 385 Server-1 1 ;Care taker for Name Server 4 386 Server-2 4 ;Care taker for Name Server 5 387 Server-3 5 ;Care taker for Name Server 6 388 Server-4 6 ;Care taker for Name Server 15 389 Server-5 15 ;Care taker for Name Server 1 391 Server-6 16 ; Comment Newly joined Name server 393 Note: The gaps in the Name server ID represents that those servers 394 have left the NS-pool either normally or abnormally. 396 Figure 4 Name Server ID Selection. 398 2.2.2.2 Choosing Care Taker ENRP Name Server 400 After computing the Name server ID, the newly registered ENRP Name 401 server chooses its care taker ENRP Name server whose NS-ID is one 402 lesser than its value. Refer Figure 4, the Care Taker Server for Name 403 Server 16 will be 15. 405 Name Server NS-ID 406 Server-1 1 ;Care taker for Name Server 4 407 Server-2 4 ;Care taker for Name Server 5 409 Ram & Senthil [Page 8] 410 Server-3 5 ;Care taker for Name Server 6 411 Server-4 6 ;Care taker for Name Server 15 412 Server-5 15 ;Care taker for Name Server 16 414 Server-6 16 ; Comment Newly joined Name server 415 ; Care taker for Name Server1 417 Figure 5 Name Server Care taker Selection/Reassignment. 419 2.2.2.3 Avoiding NS-ID Collision 421 One needs to avoid the case where two or more Name servers (say, A, B, 422 C) wishing to join a Name server pool at reasonably close points in 423 time, obtain identical Name server lists, thereby computing an identical 424 NS-ID (say, 16 as in Figure 5) for itself. When the first ENRP 425 server (A) contacts its caretaker Name server (with NS-ID 15, which is 426 say D), then a flag at D is set. When Name Server, say B, subsequently 427 contacts its caretaker Name server, which is again D, D responds with an 428 indication that the flag is set. This implies that Name server B needs 429 to retry its initialization after a certain random amount of time. The 430 same happens to Name server C. 432 After Name server A has successfully updated all other Name Servers in 433 the pool of its joining the pool, the flag at Name Server D is reset. A 434 timer associated with this flag resets the flag if the update does not 435 occur within a certain pre-specified amount of time. 437 2.3 ENRP Name Server and PE list download 439 After determining the name server ID and Caretaker Name Server, the 440 newly registered Name Server requests its Caretaker Name Server for PE 441 list by sending PE-DOWNLOAD request. 443 2.4 Name Server Updates 445 2.4.1 Name Server Status notification 447 Name Server sends the UPDATE message to other Name Servers in the NS- 448 Pool and other PEs in the AS-Pool. This message is generated due to the 449 following reasons: 451 o After the Name Server registration, successful download of Name 452 Server list and PE data, new Name server sends the Name Server update 453 list to other Servers and to the list of PE in the pool. The Update 454 message contains the NS-Parameters of the newly joined Name Server. 456 o Care taker Name Server sends the ENRP update message due to Health 457 check failure or normal shutdown of Name server. The update message 458 contains the NS-Parameter of the failed Name Server. 460 Ram & Senthil [Page 9] 461 o Name Server can extend/update its registration with the NS-pool by 462 sending UPDATE message, the typical update could be as follows 463 1. wants to extend the expiry time 464 2. wants to change the policy and control parameters 466 2.4.2. PE Status notification 468 A Name Server sends PE updates only to other Name Servers in the NS- 469 Pool. These messages are generated due to the following reasons: 471 o PE health check failure 472 o PE added to the AS-pool 473 o PE does a registration update 475 2.5 NS deRegistration and NS update 477 An NS can deRegister itself from the NS-pool, by sending 478 NS_REGISTRATION message with Expires header of value 0, to care taker 479 NS-server. NS can also de-Register one of its transport 480 addresses if it is multi homed by setting the corresponding expire 481 value to 0. 483 2.6 ENRP Health check 485 Care taker NS (Say A) will periodically check the heartbeat of each 486 transport address (in case of multi homing) of NS (say B) that it takes 487 care of. NS B upon receiving this request, responds thereby indicating 488 to A that it is alive. 490 3 Message Overview 492 ENRP is a text-based protocol and uses the ISO 10646 character set 493 in UTF-8 encoding (RFC 2279). Senders MUST terminate lines with a 494 CRLF, but receivers MUST also interpret CR and LF by themselves as 495 line terminators. 497 An ENRP message is either a request from a client to a server, or 498 a response from a server to a client. 500 ENRP-message = Request | Response 502 Both Request (section 4) and Response (section 5) messages use 503 the generic-message format of RFC 822 [2] for transferring 505 Ram & Senthil [Page 10] 506 entities (the body of the message). Both types of messages 507 consist of a start-line, one or more header fields (also known as 508 "headers"), an empty line (i.e., a line with nothing preceding the 509 carriage-return line-feed (CRLF)) indicating the end of the 510 header fields, and an optional message-body. 512 ENRP-message = start-line 513 *message-header 514 CRLF 515 [ message-body ] 517 start-line = Request-Line | ;Section 4.1 518 Status-Line ;Section 5.1 520 Table 2 provides a snapshot of the various headers within 521 ENRP. 523 message-header = Allow ; Section 6.1 524 | Expires ; Section 6.8 525 | NS-Parameter ; Section 6.2 526 | PE-Parameter ; Refer ASAP Draft 527 | Policy ; Section 6.3 528 | Periodic-Update ; Section 6.4 529 | Pool-Handle ; Refer ASAP Draft 530 | NS-ID ; Section 6.5 531 | Transaction-ID ; Section 6.7 532 | Server-Type ; Section 6.6 534 | WWW-Authenticate ; Section 6.9.1 535 | Authorization ; Section 6.9.2 536 | Authorization-Info ; Section 6.9.3 537 | Encryption ; Section 6.9.4 538 | Require ; Section 6.9.5 539 | Response-Key ; Section 6.9.6 541 Table 3: ENRP headers 543 The message syntax proposed for ASAP/ENRP satisfies the following 544 requirements: 546 - The message structure is based on well-known structures that 547 have been used in protocols that have widespread deployment. 548 - Ease of extensibility of the message structures 549 - Facilitate code reuse where possible, when other protocol 551 Ram & Senthil [Page 11] 552 parsers use similar message structures 553 - Efficient parsing of the message structures 554 - Limited processing power requirements, facilitating use of the 555 protocol in small devices. 557 4 Request 559 The syntax of request messages is as follows: 561 Request = Request-Line 562 *message-header 563 CRLF 564 [message-body] 566 4.1 Request-Line 568 The Request-Line contains a method token, followed by the 569 protocol version, and ending with CRLF. The elements are 570 separated by SP characters. No CR or LF are allowed except in 571 the final CRLF sequence. 573 Request-Line = Method SP Protocol-Version CRLF 575 When the ENRP protocol is being considered, the Request-Line is: 577 Request-Line = Method SP ENRP-Version CRLF 579 Implementations adhering to this document MUST use ENRP/1.0 for 580 their ASAP-Version. 582 4.2 Method 584 The methods are defined below. The Method token is case-sensitive. 586 Method = "NS-REGISTRATION" | "PE-DOWNLOAD" | 587 |"NS-DOWNLOAD" |"HEARTBEAT" |"UPDATE" 589 Ram & Senthil [Page 12] 590 4.2.1 NS-REGISTRAION 592 The NS-REGISTRATION method is used within a Request message that is 593 sent by a Name Server to another Name Server which is already a 594 member of a pool to indicate one of the following: 596 (a) Name Server wishes to join an NS-pool 597 (b) Name Server, which has already registered itself with an ENRP 598 server pool and is currently a member of an Name Server pool, 599 extends/modifies the duration of registration. 600 (c) Name Server, which has already registered itself with an 601 Name Server pool deletes its registration. 603 An NS cancels an existing registration by sending a NS- 604 REGISTRATION request with an expiration time (Expires header) of 605 zero seconds for a NS handle or the wildcard Endpoint 606 Addr designated by a "*" for all registrations. If a Name Server 607 handle is already found to exist, then the NS-Parameters associated 608 with it are updated. 610 4.2.2 HEARTBEAT 612 Heartbeat message are sent between an NS and its caretaker NS, in 613 order to check whether the NS is alive. 615 4.2.3 UPDATE 617 Name Server updates its database and sends the UPDATE to other 618 servers. UPDATE message can be classified into two categories 619 according to the type of updates. 621 1) The following update messages are sent by Name Servers to 622 (1) other Name Servers within the same Name Server pool, as 623 well as (2) to PE that are registered with this ENRP server 624 pool: (Refer ASAP Draft for description 625 of these messages) 627 (a) New Registration: Name Server wishes to join the server pool 629 (b) Registration Update: Name Server, which has already registered 630 itself with an ENRP pool and is currently a member of the 631 pool, wants to extend/modify the registration attributes 632 (such as duration, policy etc.). 634 (c) De-Registration: Name Server, which has already registered 635 itself with an Name Server pool, deletes its registration. 637 (c) Heartbeat Failure Notification: Name Server, which is 638 currently a member of an ENRP pool, notifies to one/more ENRP 639 servers within the pool of the heartbeat failure of another 640 Name Server within the same pool. 642 Ram & Senthil [Page 13] 643 2) The following update messages are sent by Name Servers to other 644 Name Servers: 646 (a) PE registration notification: Notifying a newly added 647 PE to the AS-pool. 649 (b) PE registration update: PE , which has already registered 650 itself with an AS-pool and is currently a member of the 651 pool, wants to extend/modify the registration attributes (such 652 as duration, policy etc.). 654 (c) PE de-registration: PE, which has already registered itself 655 with an AS-pool, deletes its registration. 657 (c) PE heartbeat failure notification: Name Server, detects the 658 failure of a PE during heartbeat check, and 659 notifies the other Name Servers within the NS-pool. 661 4.2.4 NS-DOWNLOAD 663 An NS after joining (registering) with the NS-pool, request the Name 664 Server list. 666 4.2.5 PE-DOWNLOAD 668 An NS after computing its NS-ID and identifying the 669 caretaker NS, requests PE-DOWNLOAD from its caretaker NS. 671 5 Response Header 673 After receiving and interpreting a request message, the recipient 674 responds with an ENRP response message. The response message 675 format is shown below: 677 Response = Status-Line 678 *message-header 679 CRLF 680 [ message-body ] 682 5.1 Status-Line 684 The first line of a Response message is the Status-Line,consisting 685 of the protocol version (Section 8.1.2 ) followed by a numeric 686 Status-Code and its associated textual phrase, with each element 687 separated by SP characters. No CR or LF is allowed except in the 688 final CRLF sequence. 690 Ram & Senthil [Page 14] 691 Status-Line = Protocol-version SP Status-Code SP Reason- 692 Phrase CRLF 694 When ENRP is used, the Staus-Line is: 696 Status-Line = ENRP-version SP Status-Code SP Reason- 697 Phrase CRLF 699 Implementations adhering to this document MUST use ENRP/1.0 for 700 their ENRP-Version. 702 5.1.2 Status Codes and Reason Phrases 704 The Status-Code is a 3-digit integer result code that indicates 705 the outcome of the attempt to understand and satisfy the request. 706 The Reason-Phrase is intended to give a short textual description 707 of the Status-Code. The Status-Code is intended for use by 708 automata, whereas the Reason-Phrase is intended for the human 709 user. The client is not required to examine or display the Reason- 710 Phrase. 712 Status-Code = Success ;Fig. 3 713 | Client-Error ;Fig. 4 714 | Server-Error ;Fig. 5 715 | extension-code 716 extension-code = 3DIGIT 717 Reason-Phrase = * 719 We provide an overview of the Status-Code below, and provide full 720 definitions in Section 7. The first digit of the Status-Code 721 defines the class of response. The last two digits do not have 722 any categorization role. ASAP/ENRP/1.0 allows 4 values for the 723 first digit: 725 2xx: Success -- the action was successfully received, understood, 726 and accepted; 728 4xx: Client Error -- the request contains bad syntax or cannot be 729 fulfilled at this server; 731 5xx: Server Error -- the server failed to fulfill an apparently 732 valid request; 734 Ram & Senthil [Page 15] 735 Figures 3 through 5 present the individual values of the numeric 736 response codes. 738 Success = "200" ; OK 740 Figure 3: Success status codes 742 Client-Error = "400" ; Bad Request 743 | "401" ; Unauthorized 744 | "403" ; Method Not Allowed 745 | "404" ; Not Found 746 | "409" ; Request Entity Too Large 748 Figure 4: Client error status codes 750 Server-Error = "500" ; Internal Server Error 751 | "501" ; Not Implemented 752 | "503" ; ASAP/ENRP Version not supported 754 Figure 5: Server error status codes 756 6 Header Field Definitions 758 ENRP header fields are similar to SIP or HTTP header fields 759 in both syntax and semantics. Some of these headers may be 760 present in both request and response messages, while others 761 may be present in only either a request or a response message. 762 The subsections below describing each of the headers, also 763 mentions their applicability within a request/response message. 765 6.1 Allow 767 The Allow header field is used to indicate the list of methods 768 that are supported by the responding server. 770 Allow = ("Allow" | "l") ":" *("NS-REGISTRATION" | 771 "NS-HEARTBEAT" |"UPDATE" | "NS-DOWNLOAD"|"PE-DOWNLOAD"| 772 | quoted-string) 774 An example of the Allow header is as follows: 776 Allow= "NS-REGISTRATION" "PE-DOWNLOAD" 778 Ram & Senthil [Page 16] 779 6.2 NS-Parameters 781 The NS-Parameter header is defined as follows: 783 NS-Parameter = ( "NS-Parameter" | "e" ) ":" NS-ID; Handle 785 NS-ID = ("NS-ID" | "i") ":" Digit 786 Handle = 1*("(" transport-addr ")" [*(";"contact-params )] [comment 787 ]) 789 transport-addr = IPv4|IPv6 790 IPv4 = digit "." digit "." digit "." digit *(":" port-number) 791 IPv6 = ( (digit ":" digit ":" digit ":" digit ":" digit ":" digit 792 ":" digit ":" digit) 793 |(":" digit ":" digit ":" digit ":" digit ":" digit ":" 794 digit ":" digit) 795 |(":" ":" digit ":" digit ":" digit ":" digit ":" digit ":" 796 digit) 797 |(":" ":" ":" digit ":" digit ":" digit ":" digit ":" 798 digit)) 799 *(":" port-number) 800 port-number = digit 801 contact-params = "q" "=" qvalue 802 | "Expires" "=" delta-seconds 803 | "Policy" "=" ("LRU"|"RR"|token) 804 comment = quoted-string 806 The NS-Parameter has one or more transport addresses, each of which 807 may optionally have contact parameters and comments associated 808 with them. 810 q: The "qvalue" indicates the relative preference among the 811 locations given. "qvalue" values are decimal numbers from 0 to 812 1, with higher values indicating higher preference. This could 813 be used for the case of a multi-homed host where the same service 814 may be available at different transport addresses, and a 815 preference exists for certain transport addresses. 817 6.3 Policy 819 The Policy header field is used to indicate the preferred 820 load policy of the Name Server. It is used during registration of 821 an NS-server, or when the policy associated with a registration 822 needs to be updated. 824 Policy = ("Policy" | "p") ":" ("LRU"|"RR"|token) 826 Usually, when the policy header is specified, then an Expires 827 header is included as well. This indicates the expiration time 828 associated with the policy. 830 Ram & Senthil [Page 17] 831 An example of the Policy header is as follows: 833 Policy="RR" 835 6.4 Periodic-Update 837 The Periodic-Update header may be used within a HEARTBEAT Request as 838 well as Response message. It is used within a HEARTBEAT request when 839 an Name Server requests the NS for which it is a caretaker, to 840 declare its presence to the it periodically. It is used within a 841 response to a HEARTBEAT Request when the NS indicates whether it 842 supports the periodic presence notification feature or not. 844 For example, Care taker NS (Say A) requests a periodic-update 845 heartbeat by generating the HEARTBEAT request message and including 846 the Periodic-Update header with a value "Yes" to NS (Say B). If 847 the Name Server B can report its presence periodically 848 without getting any further request from the care taker NS (A) , then 849 the Name Server B can respond to the HEARTBEAT Request 850 by including a Periodic-Update header with value of "Yes". 852 Periodic-Update = ("Periodic-Update" | "u") ":" "Yes" ";" 854 An example of the Periodic-Update header is as follows: 856 Periodic-Update="Yes" 858 6.5 NS-ID 860 The NS-ID header field is used to convey the unique identification (ID) 861 of an NS within an NS-pool. The syntax is as follows: 863 NS-ID = ("NS-ID" | "i") ":" Digit 865 Example: 867 NS-ID=2 869 6.6 Server-Type 871 The Server-Type header field is used to convey the type of server 872 that is being referred to. Currently defined server types are: NS and 873 PE. 875 Server-Type = ("Server-Type" | "r") ":" ("NS"|"PE") 877 Ram & Senthil [Page 18] 878 Example: 880 Server-Type=NS 882 6.7 Transaction-ID 884 The Transaction-ID header field is used to associate a set of 885 messages to the same transaction. Initial request messages MUST carry 886 a locally unique transaction-ID. Responses and subsequent requests 887 that are related to this request, MUST use the same Transaction-ID. 889 Transaction-ID = ("Transaction-ID" | "t") ":" UUID 891 Example: 893 Transaction-ID= "124F-AB12-874-2344-2344-1234-2345-9EDE" 895 6.8 Expires 897 The "Expires" parameter indicates how long the Name server handle is 898 valid. The parameter is a number indicating seconds. When not present, 899 the default value is taken to be the maximum, which is 2**32-1. 900 Implementations MAY treat values larger than 2**32-1 (4294967295 seconds 901 or 136 years) as equivalent to 2**32-1. 903 Expires =("Expires" | "x") ":" delta-seconds 905 Example: 907 Expires = 1000 909 6.9 Security Related Headers 911 6.9.1 WWW-Authenticate 913 The WWW-Authenticate header, typically included within a 401 Response 914 message, is used to indicate that the Requesting entity needs to be 915 authenticated. 917 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge 919 Based on RFC2617, when Digest Authentication is used, the 920 challenge is as follows: 922 challenge = "Digest" digest-challenge 924 digest-challenge = 1#( realm | [ domain ] | nonce | 925 [ opaque ] |[ stale ] | [ algorithm ] | 926 [ qop-options ] | [auth-param] ) 928 Ram & Senthil [Page 19] 929 domain = "domain" "=" <"> quoted-string <"> 930 nonce = "nonce" "=" nonce-value 931 nonce-value = quoted-string 932 opaque = "opaque" "=" quoted-string 933 stale = "stale" "=" ( "true" | "false" ) 934 algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | 935 token ) 936 qop-options = "qop" "=" <"> 1#qop-value <"> 937 qop-value = "auth" | "auth-int" | token 939 6.9.2 Authorization 941 The Authorization header is included within a Request message, so 942 that the Requesting entity may authenticate itself to the receiver. 944 Authorization = "Authorization" ":" credentials 946 Based on RFC2617, when Digest authentication is used, the 947 Authorization header is as follows: 949 credentials = "Digest" digest-response 950 digest-response = 1#( username | realm | nonce 951 | response | [ algorithm ] | [cnonce] | 952 [opaque] | [message-qop] | 953 [nonce-count] | [auth-param] ) 955 username = "username" "=" username-value 956 username-value = quoted-string 957 message-qop = "qop" "=" qop-value 958 cnonce = "cnonce" "=" cnonce-value 959 cnonce-value = nonce-value 960 nonce-count = "nc" "=" nc-value 961 nc-value = 8LHEX 962 response = "response" "=" request-digest 963 request-digest = <"> 32LHEX <"> 964 LHEX = "0" | "1" | "2" | "3" | 965 "4" | "5" | "6" | "7" | 966 "8" | "9" | "a" | "b" | 967 "c" | "d" | "e" | "f" 969 6.9.3 Authentication-Info 971 The Authentication-Info, typically included in a 200 Response 972 message, conveys any optional information following successful 973 authentication. The Authentication-Info based on RFC2617 is modified 974 by appending a token field to carry the authorization token: 976 AuthenticationInfo = "Authentication-Info" ":" auth-info 977 auth-info = 1#(nextnonce | [ message-qop ] 978 | [ response-auth ] | [ cnonce ] 979 | [nonce-count] ) 981 Ram & Senthil [Page 20] 982 nextnonce = "nextnonce" "=" nonce-value 983 response-auth = "rspauth" "=" response-digest 984 response-digest = <"> *LHEX <"> 986 6.9.4 Encryption 988 The Encryption header is used in Requests and Responses, when 989 encryption is employed. The message body and all headers following 990 a blank line are encrypted. As specified in RFC2543bis3: 992 Encryption = "Encryption" ":" encryption-scheme 1*SP 993 #encryption-params 994 encryption-scheme = token 995 encryption-params = generic-param 997 6.9.5 Require 999 The Require header is used to indicate that the recipient needs to 1000 support the specified option. As specified in RFC2543: 1002 Require = "Require" ":" 1#option-tag 1004 When an entity requires the recipient to encrypt the messages, it 1005 includes the Require header with the following option-tag: 1007 Require: org.ietf.asap.encrypt-response 1009 6.9.6 Response-Key 1011 The Response-Key header is used within a Request to indicate that the 1012 responder SHOULD use the enclosed key to encrypt responses. As 1013 specified in RFC2543: 1015 Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param 1016 key-scheme = token 1017 key-param = generic-param 1019 7 Status Code Definitions 1021 7.1 Successful 2xx 1023 The request was successful and MUST terminate a search. 1025 7.1.1 200 OK 1027 The request has succeeded. The information returned with the response 1029 Ram & Senthil [Page 21] 1030 depends on the method used in the request, for example: 1032 o ENRP_REGISTRATION: The registration has succeeded, and the ENRP 1033 Server treats the message body of the Response message according 1034 to 1035 Content 1037 o ENRP_REGISTER (Update ): The registration update has succeeded 1038 and the Name Server end point treats the message body of the 1039 Response message according to its Content 1041 o ENRP_HEARTBEAT: The heartbeat has succeed, the Name Server 1042 treats the message body according to its Content. 1044 7.2 Request Failure 4xx 1046 4xx responses are definite failure responses from a particular 1047 server. The Name Server SHOULDNOT retry the same 1048 request without modification (e.g., adding appropriate 1049 authorization). However,the same request to a different server 1050 might be successful. 1052 7.2.1 400 Bad Request 1054 The request could not be understood due to malformed syntax. 1055 The Reason-Phrase SHOULD identify the syntax problem in more 1056 detail, 1057 e.g., "Missing Handle name". 1059 7.2.2 401 Unauthorized 1061 The request requires user authentication. This could occur 1062 either when the request did not contain an Authorization header 1063 (non- compliant client), or when the Authorization header is 1064 invalid. This response is issued by 1066 (1) Name Server when the PE does registration/update/deregistration 1067 ,or 1068 (2) When PU tries to exchange data with PE, or 1069 (3) When PU tries to NAME-RESOLUTION request with Name Server 1071 7.2.3 403 Method Not Allowed 1073 The method specified in the Request-Line is not allowed for the 1074 receipt. The response MUST include an Allow header field 1075 containing a list of valid methods supported by the recipient. 1077 7.2.4 404 Not Found 1079 Ram & Senthil [Page 22] 1080 The server has definitive information that the resource does not 1081 exist. For instance, when a PU sends a NAME-RESOLUTION Request to 1082 the Name Server and the Pool Handle contained therein does not 1083 exist, then the Name Server returns a 404 Response. 1085 7.2.5 409 Request Entity Too Large 1087 The PE or Name Server is refusing to process a request 1088 because the request entity is larger than the server is willing 1089 or able to process. The server MAY close the connection to 1090 prevent the client from continuing the request. 1092 The requesting entity may retry the request at a later time. 1094 7.3 Server Failure 5xx 1096 5xx responses are failure responses given when a server itself 1097 has errored. They are not definitive failures, and the 1098 requesting entity MUST NOT terminate a search if other possible 1099 locations remain untried. 1101 7.3.1 500 Server Internal Error 1103 The Name Server encountered an unexpected condition that 1104 prevented it from fulfilling the request. The client MAY 1105 display the specific error condition, and MAY retry the 1106 request after several seconds. 1108 The client may retry the request at a later time. 1110 7.3.2 501 Not Implemented 1112 The Name Server does not support the functionality required to 1113 fulfill the request. This is the appropriate response when it 1114 does not recognize the request method and is not capable of 1115 supporting it. 1117 7.3.3 502 Service Unavailable 1119 The ENRP Name server or PE is currently unable to handle the 1120 request due to a temporary overloading or maintenance of the 1121 server. The implication is that this is a temporary condition 1122 which will be alleviated after some delay. 1124 Note: The existence of the 502 status code does not imply that a 1125 server has to use it when becoming overloaded. Some servers MAY 1126 wish to simply refuse the connection. 1128 Ram & Senthil [Page 23] 1129 7.3.4 503 Version Not Supported 1131 The Name Server does not support, or refuses to support, 1132 the ASAP/ENRP protocol version that was used in the request 1133 message. The PE is indicating that it is unable or 1134 unwilling to complete the request using the same major 1135 version as the client, other than with this error message. 1137 8. Behavior of Name Server 1139 8.1 NS - Startup and Shutdown interaction Messages 1141 This section describes the rules for Name Servers for generating 1142 and processing requests and responses during startup. 1144 8.1.1 Registering Entity Resolves the Name Server with which to 1145 Register 1147 Prior to registering an Name Server with an NS-pool, the registering 1148 entity needs to resolve the IP address of an Name Server(s) with 1149 which it registers. 1151 Several mechanisms are possible, whereby the registering entity 1152 can determine the IP address of an Name Server to register with. 1153 For instance, (1) a registering entity may be manually configured 1154 with a set of IP addresses of Name Servers that it may register 1155 with, or (2) a registering entity may be configured with the DNS 1156 address of a Name Server(s) that it may register with following 1157 which it uses a DNS query and local policy to determine the 1158 specific IP address of the Name Server to register with, or 1159 (3) the Service Location Protocol (SLP) may be used to discover a 1160 suitable Name Server. 1162 We briefly describe a possible operation procedure when DNS is 1163 used. The registering entity is configured with the DNS address of 1164 an Name Server(s)that it may register with. It performs a DNS 1165 query which returns a set of IP addresses corresponding to the 1166 queried DNS address. Based on this returned list of IP addresses 1167 and any local policies, the registering entity selects an IP 1168 address for registration. 1170 While the selection of IP address is implementation specific, a 1171 sample procedure for selection of IP address is indicated below: 1173 (a) Selection criterion is based on the order of returned IP 1174 addresses. In other words, the first IP address in the list 1175 could be used for registration. If the registration fails, 1176 the next IP address in the list is tried, and so on. 1178 (b) Selection criterion is based on a random selection of returned 1179 IP addresses from the DNS query. 1181 Ram & Senthil [Page 24] 1182 It may be noted that the above specified mechanisms are outside 1183 the scope of the ASAP/ENRP protocol itself, and that the above 1184 specified mechanisms are possible ways of resolving the IP 1185 address of the Name Server. 1187 8.1.2 Joining Name Server needs to be registered with an NS 1189 An Name Server may register with an NS-pool by 1190 contacting one of the NS in the pool. The registering Name Server 1191 resolves the IP address of the Name Server to register with, as 1192 specified in Section 8.1.1. 1194 In order to register with the selected IP address, the Name Server 1195 sends a Request message to the selected IP address with method 1196 set to NS-REGISTRATION. Implementations adhering to this document 1197 MUST set the ENRP-version field to ENRP/1.0. Hence, the Request- 1198 line is as follows: 1200 NS-REGISTRATION ENRP/1.0 1202 For instance, a typical Register-Request message may look like 1203 this: 1205 NS-REGISTRATION ENRP/1.0 1206 Transaction-ID=0xde34682a 1207 Expires: 7200 1208 Authorization: 1210 An Name Server MUST be authenticated before it can register 1211 with an Name Server. In order to handle such authentication, the 1212 ENRP Registration Request message can optionally include an 1213 Authorization header. Security procedures are described Section 9. 1215 8.1.3 Name Server De-Registering itself from the Pool 1217 An Name Server that wishes to withdraw its services from an NS-pool, 1218 does so by issuing a suitable de-register message to the 1219 Name Server(s) and also to the PE. An explicit de- 1220 register message is not provided for the purpose. Instead, de- 1221 registration is inferred by the use of a NS-REGISTRATION message 1222 with an Expires header field of value 0. 1224 For instance, a typical Register-Request message that is used for 1225 De-Registration purposes may look like this: 1227 Ram & Senthil [Page 25] 1228 NS-REGISTRATION ENRP/1.0 1229 Transaction-ID=0x34ae78d 1230 Expires: 0 1231 Authorization: 1232 NS-ID: 3 1234 8.1.4 Download of ASAP/ENRP pool element information on to NS 1236 8.1.4.1 Name Server Requests list of Name Servers in NS-pool 1238 After NS (say A) has successfully registered itself with 1239 an NS-pool by sending an NS-REGISTRATION request message to 1240 an NS (say B) in the NS-pool, it needs to obtain the list of ENRP 1241 servers in the pool. This is obtained by the NS A sending an 1242 NS-DOWNLOAD request message to NS B (which is the NS 1243 server that it got the registration response from.) 1245 The format of the Request-Line of an NS-DOWNLOAD request message is 1246 as follows 1248 NS-DOWNLOAD ENRP/1.0 1250 A typical message is as follows: 1252 NS-DOWNLOAD ENRP/1.0 1253 Transaction-ID=0x34ae78d 1254 Authorization: 1256 8.1.4.2 Response to NS-DOWNLOAD message requesting Name Server list 1258 After an NS (say A) has successfully registered itself with 1259 an NS-pool by sending an NS-REGISTRATION request message to an 1260 NS (say B) in the NS-pool, it needs to obtain the list of NS 1261 servers in the pool. This is obtained by the NS A sending an 1262 NS-DOWNLOAD request message to NS B (which is the NS that it got the 1263 registration response from.) 1265 When NS B receives such an NS-REGISTRATION request message, it 1266 responds by sending a sequence of NS-Parameters. The NS-Parameter 1267 provides information on parameters such as IP addresses), policy, 1268 timers, NS-ID etc. 1270 An example of a successful response to an NS-DOWNLOAD message is 1271 as follows. Here, three Name Servers (with IDs 1,2 and 3) are present 1272 in the NS-pool. Name Server with NS-ID 1 is a multi- 1273 homed server with two interfaces - one with transport address 1274 172.19.134.20:568 and the other with transport address 1275 172.19.134.21:568. On the other hand, Name Server with NS-ID of 2 and 1276 3, each have a single interface. 1278 Ram & Senthil [Page 26] 1279 200 ENRP/1.0 1280 Transaction-ID=0x34ae78d 1281 NS-Parameter:1; 1282 172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000; 1283 NS-Parameter:2;172.19.45.4:40;Expires:65000 1284 NS-Parameter:3;172.20.65.45:568;Expires:42000 1285 Policy: RR 1286 Authorization: 1288 After the requesting NS receives the list of NS-Parameters 1289 based on a successful NS-DOWNLOAD request, it computes its NS-ID by 1290 suitable navigation of the existing NS-IDs in the NS-ID list. (see Sec 1291 2.2.2). Determination of the caretaker Name Server is also made by the 1292 NS at this point (see Sec 2.2.2). 1294 8.1.4.3 NS requests PE list from caretaker NS 1296 An NS queries its caretaker NS for a list of PE, by sending an NS- 1297 DOWNLOAD message. The Server-Type header is set to PE to denote that the 1298 list of PE is queried 1299 for. 1301 An example of an NS-DOWNLOAD message is as follows: 1303 NS-DOWNLOAD ENRP/1.0 1304 Transaction-ID=0x34ae78d 1305 Server-Type: PE 1306 Authorization: 1308 8.1.4.4 Response to NS-DOWNLOAD message requesting PE list 1310 Upon receiving an NS-DOWLOAD request message with Server-Type set 1311 to PE, the caretaker NS responds with a list of PE-Parameters. The PE- 1312 Parameter includes information such as the 1313 IP addresses), policy, timers, and NS-ID of Name 1314 Server which is responsible for performing health check. 1316 An example usage of this message is as follows. Here, Name Server 1317 with NS-ID of 1 is the caretaker NS for two PEs 1318 within the AS-pool www.foo.com. The first PE is multi-homed 1319 with two interfaces - transport address of 172.19.134.20:568 and 1320 172.19.134.21:568. The second PE has a single interface with transport 1321 address of 172.19.45.4:40. 1323 Also, illustrated in the message below is the usage of proxies. The 1324 NS with NS-ID of 2 is the caretaker Name Server for a 1325 legacy application server with transport address of 172.20.65.45:568, 1326 and the proxy PE that is responsible for handling the legacy application 1327 server has an transport address of 145.45.65.30:657. 1329 Ram & Senthil [Page 27] 1330 200 ENRP/1.0 1331 Transaction-ID=0x34ae78d 1332 Server-Type: PE 1333 Pool-Handle: www.foo.com 1334 NS-ID:1 1335 PE-Parameter: 1336 172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000 1337 NS-ID:1 1338 PE-Parameter: 172.19.45.4:40;Expires:65000 1339 NS-ID:2 1340 PE-Parameter: 172.20.65.45:568;Expires:42000;Proxy- 1341 Addr:145.45.65.30:657 1342 Policy: RR 1343 Authorization: 1345 8.2 Interaction between a pair of NS 1347 The following messages are generated by Name Server in the NS-pool to 1348 other Name Servers and to PE to notify changes of NS in the NS-pool. 1350 8.2.1 NS Updates NS status to PEs and other NS in the NS-Pool 1352 The following update messages are sent by Name Servers to 1353 (1) all other Name Servers within the same NS-pool, as well 1354 as (2) to all PE that are registered with this 1355 NS-pool: 1357 (a) New NS Registration Notification: When an NS (say, 1358 A) wishes to join the NS-pool, it registers itself 1359 with an NS (say, B) that is already in the NS-pool. NS B then 1360 uploads suitable information (including the current list of NS in 1361 the pool as well as the current list of PE that are managed by 1362 this NS-pool) to Name Server A. 1363 Name Server A then notifies all Name Servers and PE 1364 about its new registration. (Sec 8.2.1.1) 1366 (b) NS Registration Update: Name Server, which has already 1367 registered itself with an NS-pool and is currently a member 1368 of the pool, wants to extend/modify the registration 1369 attributes (such as duration, policy etc.). (Sec 8.2.1.2) 1371 (c) NS De-Registration Notification: Name Server, which has 1372 already registered itself with an NS-pool, deletes 1373 its registration by notifying its caretaker Name Server. 1374 After receiving such de-registration message from an NS, the 1375 caretaker NS-server notifies all other NS in the NS-pool of this 1376 de-registration. (Sec 8.2.1.3 ) 1378 (d) Heartbeat Failure Notification: Name Server, which is currently 1380 Ram & Senthil [Page 28] 1381 a member of an NS-pool, notifies to one/more Name Servers 1382 within the pool of the heartbeat failure of another NS within 1383 the 1384 same pool. (Sec 8.2.1.3 ) 1386 8.2.1.1 New NS Registration Notification 1388 Newly added Name Server sends its update message to the other NS and 1389 PE. This informs that the new NS is part of the NS-pool. 1391 NS-UPDATE with Server-Type = ENRP and NS-ID refers to the 1392 Name Server ID which has joined the pool. 1394 For instance, NS-UPDATE message may look like this: 1396 NS-UPDATE ENRP/1.0 1397 Transaction-ID=0x34ae78d 1398 Expires: 10000 1399 Server-Type:ENRP 1400 NS-Parameter: NS-ID:2;172.20.65.45:568;Expires:42000; 1401 Authorization: 1403 8.2.1.2 NS Registration Update 1405 An Name Server that is already in an NS-pool may update 1406 its registration. Such update could include modification of 1407 registration attributes (e.g. expiration time of the registration, 1408 policy associated with the registration etc.). Registration 1409 updates are performed using a Request message with the NS-UPDATE 1410 method. 1412 NS-UPDATE with Server-Type = ENRP and NS-ID refers to 1413 the NS which has updated its registration attributes. 1415 For instance, when an NS wishes to increase its 1416 registration expiration to a new value of 10000 seconds, then a 1417 Request message as follows is sent: 1419 NS-UPDATE ENRP/1.0 1420 Transaction-ID=0x34ae78d 1421 Server-Type:ENRP 1422 NS-Parameter: NS-ID:2;172.20.65.45:568;Expires:10000; 1423 Authorization: 1425 8.2.1.3 NS Heart beat Failure or NS de-Registration Notification 1426 Updates 1428 Ram & Senthil [Page 29] 1429 Caretaker Name Server updates all the other Name Servers and PE in 1430 the event of Name Server heartbeat failures or de-Registration. Note 1431 that the NS-ID represents the Name Server which has to be 1432 removed from the NS-pool.Expires value is set to 0. 1434 NS-UPDATE with Server-Type = ENRP and NS-ID refers to the NS which is 1435 no more part of the NS-pool. 1437 For instance, an NS-UPDATE may look like: 1439 NS-UPDATE ENRP/1.0 1440 Transaction-ID=0x34ae78d 1441 Expires: 0 1442 Server-Type:ENRP 1443 NS-ID: 3 1444 Authorization: 1446 8.2.2 Name Server updating a PE Status to all NS 1448 The following update messages, dealing with the update of PE, are 1449 sent by an NS to other NS in the NS-pool: 1451 (a) PE registration notification: Notifying a newly added 1452 PE to the server pool. 1454 (b) PE registration update: PE , which has 1455 already registered itself with an AS-pool and is 1456 currently a member of the pool, wants to extend/modify the 1457 registration attributes (such as duration, policy etc.). 1459 (c) PE de-registration notification: PE , which has already 1460 registered itself with an AS-pool, deletes its registration. 1462 (d) PE heartbeat failure notification: NS, 1463 detects the failure of a PE during heartbeat 1464 check, and notifies the other NSs within the NS-pool. 1466 8.2.2.1 PE registration notification 1468 NS updates other NS(s) regarding newly registered PE .Name 1469 Server which has received the PE-REGISTRATION request chooses Caretaker 1470 NS for that PE. NS-ID denotes the Caretaker NS for that PE. The 1471 caretaker NS is responsible for health check of the PE. 1473 An example is as follows: 1475 NS-UPDATE ENRP/1.0 1476 Transaction-ID=0x34ae78d 1477 PE-Parameter:172.19.146.54:675 1479 Ram & Senthil [Page 30] 1480 Policy:LRU 1481 Expires: 10000 1482 NS-ID: 3 1483 Authorization: 1485 This implies that the PE with PE-Parameter "172.19.146.54:675" has been 1486 assigned a caretaker NS with NS-ID of 3. 1488 Alternatively, the application server may be a legacy application 1489 server that does not support ASAP/ENRP protocols. Such an application 1490 server may rely on proxy PE to act on its behalf. In this 1491 case, the proxy PE would register the application server with the NS. 1492 When the NS performs a registration notification to 1493 other NSs, it then needs to include both the transport 1494 address of the legacy application server, as well as the transport 1495 address of the proxy PE. The transport address of the legacy application 1496 server is needed in order to respond to a query by a PU (i.e., a NAME- 1497 RESOLUTION REQUEST message). The transport address of the proxy PE is 1498 needed for heartbeat check. An example is as follows: 1500 NS-UPDATE ENRP/1.0 1501 Transaction-ID=0x34ae78d 1502 PE-Parameter:172.19.146.54:675;Proxy: 172.20.43.45:45 1503 Policy:LRU 1504 Expires: 10000 1505 Authorization: 1506 NS-ID: 3 1508 This implies that the PE with PE-Parameter "172.19.146.54:675;Proxy: 1509 172.20.43.45:45" has been assigned a caretaker NS with NS-ID of 3. 1511 8.2.2.2 PE registration update 1513 Caretaker NS updates other NS(s) regarding a registration update to an 1514 already registered PE. This is invoked when the caretaker NS has 1515 received the PE-REGISTRATION request message indicating the update. 1517 An example of an NS-UPDATE request message is as follows: 1519 NS-UPDATE ENRP/1.0 1520 Transaction-ID=0x34ae78d 1521 PE-Parameter:172.19.146.54:675 1522 Policy:LRU 1523 Expires: 10000 1524 Authorization: 1526 8.2.2.3 PE de-registration or interface heartbeat failure 1527 notification 1529 Ram & Senthil [Page 31] 1530 An PE may have multiple interfaces by which it may be 1531 reached. This is the case of a multi-homed PE . In such a 1532 case, the NS needs to be aware of the availability of 1533 each interface associated with the PE . Thus, heartbeat 1534 check is done for each interface, and any failure of such an 1535 interface heartbeat check is notified to all the NSs. 1537 A multi-homed PE may de-register one/more/all of its 1538 interfaces associated with it. The caretaker NS that 1539 receives such a de-registration request message, also sends an 1540 NS-UPDATE message to all the NSs notifying them of 1541 such de-registration. 1543 The caretaker NS updates its ENRP database and sends an 1544 NS-UPDATE message with the Expires field set to 1545 zero, to other NSs. 1547 For instance, an NS-UPDATE may be as follows: 1549 NS-UPDATE ENRP/1.0 1550 Transaction-ID=0x34ae78d 1551 PE-Parameter:172.19.146.54:675 1552 Expires: 0 1553 Authorization: 1555 In the above example, the de-registration applies to the transport 1556 address indicated in the PE-Parameter header. Alternatively, the 1557 Expires field within the PE-Parameter header may be set to zero in order 1558 to indicate de-registration. 1560 For instance, an example of the usage of this would be: 1562 NS-UPDATE ENRP/1.0 1563 Transaction-ID=0x34ae78d 1564 PE-Parameter:172.19.146.54:675;expires=0 1565 Policy:LRU 1566 Authorization: 1568 8.2.3 Caretaker NS sends a Heartbeat Request to other NSs in NS-Pool 1570 Associated with each NS is a caretaker NS. The caretaker NS is 1571 responsible for heartbeat check of the NS under its care. A 1572 caretaker NS will send the HEARTBEAT request to the NS under its 1573 care, to examine whether the NS is alive. The format of the 1574 Request-Line of a HEARTBEAT request message is as follows: 1576 HEARTBEAT ENRP/1.0 1578 An example of a heartbeat request is as follow s: 1580 Ram & Senthil [Page 32] 1581 HEARTBEAT ENRP/1.0 1582 Transaction-ID=0x34ae78d 1583 Periodic-Update: Yes;600 1584 Authorization: 1586 The heartbeat check that a caretaker NS performs is done on 1587 a per-interface basis for the NS under its care. If an ENRP 1588 server is multi-homed and has several interfaces by which the ENRP 1589 server may be reached, then the caretaker NS may need to 1590 poll (send HEARTBEAT request to) each interface associated with the 1591 NS under its care. 1593 8.2.4 NS sends Heartbeat Response to Care-Taker NS 1595 Upon receiving a Heartbeat Request from its caretaker NS, an 1596 NS responds back to its caretaker NS with a Heartbeat Response 1597 message. The response indicates whether a Periodic- 1598 Update is supported or not. 1600 The format of HEARTBEAT response message is as follows: 1602 200 ENRP/1.0 1603 Transaction-ID=0x34ae78d 1604 Periodic-Update: Yes 1605 Authorization: 1607 The interface from which the response to the heartbeat request message 1608 is received, is the interface that corresponds to the heartbeat 1609 response. 1611 8.2.5 NS notifies all other NSs in NS-pool of a change in 1612 caretaker NS 1614 This is the case of a change of caretaker NS notification. 1615 When the caretaker NS of a PE changes, then such a 1616 change needs to be notified to all NSs in the NS-pool. 1618 NS-UPDATE ENRP/1.0 1619 Transaction-ID=0x34ae78d 1620 NS-ID:1; 1621 PE-Parameter: 1622 172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000 1623 NS-ID:2; 1624 PE-Parameter: 172.19.45.4:40;Expires:65000 1625 Policy:LRU 1626 Expires: 10000 1627 Authorization: 1629 This implies that the PE with PE-Parameter of 1630 "172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000" is 1631 assigned a caretaker NS with NS-ID of 1. Similarly, the PE with PE- 1632 Parameter of "172.19.45.4:40;Expires:65000" has been assigned a 1633 caretaker NS with NS-ID of 2. 1635 9 Security Considerations 1637 9.1 Confidentiality and Privacy: Encryption 1639 9.1.1 Application-Level Encryption 1641 Using public-key or shared-key based mechanisms, some or all headers 1642 as well as the message body within a Request and/or Response may be 1643 encrypted. The Encryption header is included to indicate the 1644 encryption mechanism employed. A blank line is used to indicate the 1645 start of encryption, and all headers following the blank line and the 1646 message body are encrypted. The mechanism follows that in RFC2543. 1648 9.1.2 Lower-Layer Encryption 1650 In addition or instead of application layer encryption techniques, lower 1651 layer encryption techniques (e.g.IPSec, TLS, or link layer) may be 1652 employed. Such encryption may provide certain benefits, 1653 such as better protection against traffic analysis attacks (e.g. 1654 using link layer encryption). 1656 9.2 Message Integrity and Access Control: Authentication 1658 The ENRP protocol utilizes mechanisms provided within HTTP and SIP 1659 for message integrity and/or authentication purposes. The Basic and 1660 Digest authentication schemes may be used for authentication. In 1661 addition, public-key based mechanisms may also be used. Irrespective 1662 of the type of authentication mechanism, the following procedure is 1663 adopted: 1665 - The WWW-Authenticate header is used within a 401 Response 1666 message, by the authenticator in order to indicate the 1667 authenticating mechanism and possibly the challenge. 1668 - The Authorization header is used within a re-issued Request 1669 message, in order to pass the authenticating information to the 1670 Authenticator. 1671 - The Authentication-Info header is used within a 200 Response 1672 message, by the authenticator in order to pass any token that may 1673 be needed by the entity that sent the Request message. 1675 Typically, all communication needs to be authenticated. 1677 9.2.1 Illustration of Digest Scheme 1679 While we illustrate the use of the Digest authentication scheme here, 1681 Ram & Senthil [Page 34] 1682 a similar approach may be followed for other authentication schemes - 1683 Basic authentication, public-key based authentication etc. 1685 When an NS first registers with an NS in an NS-pool: 1687 - An NS (say, A) first registers with an NS (say B) in an NS-pool 1688 by sending a NS-REGISTRATION Request message without the 1689 Authorization header. 1690 - The NS B in the NS-pool returns a 401 Response message with a 1691 WWW-Authenticate header indicating that Digest authentication is 1692 needed. 1693 - The NS A sends a new NS-REGISTRATION Request message with an 1694 Authorization header included, in order to authenticate itself. 1695 - Upon successful authentication, the NS B returns a 200 1696 Response message. An Authentication-Info header is included, and 1697 this contains a session key that all the NSs in the NS-pool share. 1699 For subsequent interactions between a pair of NS in the NS-pool: 1701 - All messages include an Authenticating Code within the 1702 Authorization header. The Authenticating Code is based on the 1703 session key shared by all the NS in the NS-pool. 1705 Appendix 1707 A. Implementation Issues 1709 For Implementation issues Refer ASAP draft Appendix A for more 1710 detail. 1712 B. Summary of Augmented BNF 1714 Please refer to [RFC2543] for a summary. 1716 C. Acknowledgement 1718 We wish to thank the Maureen Stillman and John Loughney for providing 1719 valuable comments and suggestions. 1721 Ram & Senthil [Page 35] 1722 D. Author's Contact Address 1724 Ram Gopal.L 1725 Senthil Sengodan 1727 Nokia Research Center 1728 5 Wayside Road 1729 Burlington, MA 01803 1730 USA 1732 email: ram.gopal@nokia.com 1733 senthil.sengodan@nokia.com 1735 E. Reference 1737 [RFC 822 ] 1738 D. Crocker, "Standard for the format of ARPA Internet text 1739 messages," Request for Comments 822, Internet Engineering Task 1740 Force,Aug. 1982. 1742 [RFC2026] 1743 S. Bradner, "The Internet Standards Process -- Revision 3", 1744 RFC 2026, October 1996. 1746 [RFC 2234] 1747 D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax 1748 specifications: ABNF," Request for Comments 2234, Internet 1749 Engineering Task Force, Nov. 1997 1751 [RFC 2279 ] 1752 F. Yergeau, "UTF-8, a transformation format of ISO 10646," 1753 Request for Comments 2279, Internet Engineering Task Force, Jan. 1754 1998. 1756 [RFC2616] 1757 R. Fielding et al. Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, 1758 Internet Engineering Task Force, June 1999 1760 [RFC 2617] 1761 J. Franks et al, HTTP Authentication: Basic and Digest Access 1762 Authentication, RFC 2617 Internet Engineering Task Force, June 1999 1764 [RFC2960] 1765 R. R. Stewart et al., "Stream Control Transmission 1766 Protocol", RFC 2960, November 2000 1768 [ASAP-Draft] 1770 Ram Gopal and Senthil Sengodan , "Aggregate Server Access Protocol 1771 Candidate ",draft-gopal-asap-candidate-00.txt, July, 2001. 1773 Ram & Senthil [Page 36] 1774 [Papoulis] 1775 A.Papoulis, Probability, Random Variables, and Stochastic Processes, 1776 3rd Edition, McGraw Hill Publication. 1778 [Mullender] 1779 Sape Mullender , Distributed Systems, 2nd Edition, Addison-Wesley 1781 [Rser-Arch] 1782 M. Tuexen, "Architecture for Reliable Server Pooling", 1783 Internet Draft,draft-ietf-rserpool-arch-00.txt, April, 2001. 1785 [Rser-Comp] 1786 J. Loughney, "Comparison of Protocols for Reliable Server Pooling", 1787 Internet draft,draft-ietf-rserpool-comp-00.txt, May 1,2001 1789 [Rser-req] 1790 M. Tuexen,"Requirements for Reliable Server Pooling", 1791 Internet draft,draft-ietf-rserpool-reqts-03.txt,May 9 2001 1793 [SIP Draft] 1794 Handley, "Session Initiation Protocol",Internet draft, 1795 draft-ietf-sip-rfc2543bis-02.txt, Nov 2000. 1797 [Stevens] 1798 W. R. Stevens, TCP/IP illustrated: the protocols , Vol. 1. 1799 Reading, Massachusetts: Addison-Wesley, 1994.