draft-ietf-rserpool-asap-04.txt   draft-ietf-rserpool-asap-05.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: December 29, 2002 Q. Xie Expires: May 1, 2003 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Siemens AG Siemens AG
June 30, 2002 October 31, 2002
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-04.txt draft-ietf-rserpool-asap-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2002. This Internet-Draft will expire on May 1, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Name Resolution Protocol (ENRP) [6] provides a high Endpoint Name Resolution Protocol (ENRP) [6] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
skipping to change at page 3, line 22 skipping to change at page 3, line 22
1.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
2. Message Definitions . . . . . . . . . . . . . . . . . . . 8 2. Message Definitions . . . . . . . . . . . . . . . . . . . 8
2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8
2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . . . 9 2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . . . 9
2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . . . 9 2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . . . 9
2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . . . 10 2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . . . 10
2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . . . 10 2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . . . 10
2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11 2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11
2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11 2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11
2.2.7 NAME_UNKNOWN message . . . . . . . . . . . . . . . . . . . 12 2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12
2.2.8 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 12
2.2.9 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 12 2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13
2.2.10 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13 2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . . . . 13
2.2.11 SERVER_HUNT message . . . . . . . . . . . . . . . . . . . 13 2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 14
2.2.12 SERVER_HUNT_RESPONSE message . . . . . . . . . . . . . . . 13 2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14
2.2.13 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 13 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . . . . 14
2.2.14 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14 2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 15
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 16 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 17 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18
3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 18 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19
3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 19 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20
3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 19 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20
3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 20 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 21
3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 20 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 22
3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 20 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 22
3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 21 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 22
4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 22 3.9 Business Card handling procedures . . . . . . . . . . . . 23
4.1 Registration.Request Primitive . . . . . . . . . . . . . . 22 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 24
4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 22 4.1 Registration.Request Primitive . . . . . . . . . . . . . . 24
4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 23 4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 24
4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 23 4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 25
4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 23 4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 25
4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 24 4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 25
4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 25 4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 26
4.5.2.1 Round Robin Policy . . . . . . . . . . . . . . . . . . . . 25 4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 27
4.5.2.2 Least Used Policy . . . . . . . . . . . . . . . . . . . . 25 4.5.2.1 Round Robin Policy . . . . . . . . . . . . . . . . . . . . 27
4.5.2.3 Least Used with Degradation Policy . . . . . . . . . . . . 26 4.5.2.2 Least Used Policy . . . . . . . . . . . . . . . . . . . . 27
4.5.2.4 Weighted Round Robin Policy . . . . . . . . . . . . . . . 26 4.5.2.3 Least Used with Degradation Policy . . . . . . . . . . . . 28
4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 26 4.5.2.4 Weighted Round Robin Policy . . . . . . . . . . . . . . . 28
4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 27 4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 28
4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 27 4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 29
4.6 Data.Received Notification . . . . . . . . . . . . . . . . 28 4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 29
4.7 Error.Report Notification . . . . . . . . . . . . . . . . 29 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 30
4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 31
4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 29 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 31 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 31
4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 31 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 33
4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 31 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 33
4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 32 4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 33
5. Variables, Timers, and Thresholds . . . . . . . . . . . . 33 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 34
5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5. Variables, Timers, and Thresholds . . . . . . . . . . . . 35
5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 33 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . 34 5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 35
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . 36
Normative References . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 37
Informational References (non-normative) . . . . . . . . . 37 Normative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 37 Informational References (non-normative) . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6] Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6]
provides a high availability data transfer mechanism over IP provides a high availability data transfer mechanism over IP
networks. ASAP uses a name-based addressing model which isolates a networks. ASAP uses a name-based addressing model which isolates a
logical communication endpoint from its IP address(es), thus logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication effectively eliminating the binding between the communication
endpoint and its physical IP address(es) which normally constitutes a endpoint and its physical IP address(es) which normally constitutes a
single point of failure. single point of failure.
skipping to change at page 5, line 34 skipping to change at page 5, line 34
PE. In other words, ASAP is capable of transparent fail-over amongst PE. In other words, ASAP is capable of transparent fail-over amongst
instances of a server pool. instances of a server pool.
ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a
high availability name space. ASAP is responsible for the high availability name space. ASAP is responsible for the
abstraction of the underlying transport technologies, load abstraction of the underlying transport technologies, load
distribution management, fault management, as well as the distribution management, fault management, as well as the
presentation to the upper layer (i.e., the ASAP user) a unified presentation to the upper layer (i.e., the ASAP user) a unified
primitive interface. primitive interface.
When SCTP RFC2960 [4]. is used as the transport layer protocol, ASAP When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP
can seamlessly incorporate the link-layer redundancy provided by the can seamlessly incorporate the link-layer redundancy provided by the
SCTP. SCTP.
This document defines the ASAP portion of the high availability This document defines the ASAP portion of the high availability
server pool. ASAP depends on the services of a high availability server pool. ASAP depends on the services of a high availability
name space a.k.a. ENRP [6]. name space a.k.a. ENRP [6].
1.1 Definitions 1.1 Definitions
This document uses the following terms: This document uses the following terms:
skipping to change at page 6, line 23 skipping to change at page 6, line 23
Pool Element handle (PE handle): A logical pointer to a particular Pool Element handle (PE handle): A logical pointer to a particular
Pool Element in a pool, Pool Element in a pool,
ENRP server: A server program running on a host that manages the name ENRP server: A server program running on a host that manages the name
space collectively with its peer ENRP servers and replies to the space collectively with its peer ENRP servers and replies to the
service requests from any Pool User or Pool Element. service requests from any Pool User or Pool Element.
Home ENRP server: The ENRP server to which a Pool Element currently Home ENRP server: The ENRP server to which a Pool Element currently
uses. A PU or PE normally chooses the ENRP server on their local uses. A PU or PE normally chooses the ENRP server on their local
host as the home ENRP server (if one exists). A PU or PE should host as the home ENRP server (if one exists). A PU or PE should
only have one home ENRP server at any given time. Note that the only have one home ENRP server at any given time. Having a "home"
"home" ENRP server concept exists only within ASAP. ENRP servers ENRP server helps provide a mechanism to minimize the number of
provide no special handling of PE's or PU's. Having a "home" ENRP
server only provides a mechanism to minimize the number of
associations a given PE will have. associations a given PE will have.
ENRP client channel: The communication channel through which an ASAP ENRP client channel: The communication channel through which an ASAP
User (either a PE or PU) requests ENRP namespace service. The User (either a PE or PU) requests ENRP namespace service. The
client channel is usually defined by the transport address of the client channel is usually defined by the transport address of the
home server and a well known port number. The channel MAY make home server and a well known port number. The channel MAY make
use of multi-cast or a named list of ENRP servers. use of multi-cast or a named list of ENRP servers.
ENRP server channel: Defined by a well known multicast IP address and ENRP server channel: Defined by a well known multicast IP address and
a well known port number, OR a well known list of transport a well known port number, OR a well known list of transport
skipping to change at page 8, line 39 skipping to change at page 8, line 39
Type Message Name Type Message Name
----- ------------------------- ----- -------------------------
0x00 - (reserved by IETF) 0x00 - (reserved by IETF)
0x01 - Registration 0x01 - Registration
0x02 - Deregistration 0x02 - Deregistration
0x03 - Registration Response 0x03 - Registration Response
0x04 - Deregistration Response 0x04 - Deregistration Response
0x05 - Name Resolution 0x05 - Name Resolution
0x06 - Name Resolution Response 0x06 - Name Resolution Response
0x07 - Name Unknown 0x07 - Endpoint Keep Alive
0x08 - Endpoint Keep Alive 0x08 - Endpoint Keep Alive Acknowledgement
0x09 - Endpoint Keep Alive Acknowledgement 0x09 - Endpoint Unreachable
0x0a - Endpoint Unreachable 0x0a - Server Announce
0x0b - Server Hunt 0x0b - Cookie
0x0c - Server Hunt Response 0x0c - Cookie-Echo
0x0d - Cookie 0x0d - Business Card
0x0e - Cookie-Echo 0x0e - Peer Error
2.2.1 REGISTRATION message 2.2.1 REGISTRATION message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x1 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The pool handle parameter field specifies the name to be registered. The pool handle parameter field specifies the name to be registered.
The PE Parameter field shall be filled in by the registrant endpoint The PE Parameter field MUST be filled in by the registrant endpoint
to declare its transports and addresses, server pooling policy and to declare its transports and addresses, server pooling policy and
value, and other operation preferences. Note that the registration value, and other operation preferences. Note that the registration
message MUST use SCTP and the IP addresses of the PE registered message MUST use SCTP and the IP addresses of the PE registered
within the Pool Element Parameter MUST be a subset of the addresses within the Pool Element Parameter MUST be a subset of the addresses
of the SCTP association irrespective of the transport protocol of the SCTP association irrespective of the transport protocol
regestered by the PE. regestered by the PE.
2.2.2 DEREGISTRATION message 2.2.2 DEREGISTRATION message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier Parameter | : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
The PE sending the DEREGISTRATION shall fill in the pool handle and The PE sending the DEREGISTRATION shall fill in the pool handle and
the PE identifier parameter in order to allow the ENRP server to the PE identifier parameter in order to allow the ENRP server to
verify the identity of the endpoint. Note that deregistration is NOT verify the identity of the endpoint. Note that deregistration is NOT
allowed by proxy, in other words only a PE may only deregister allowed by proxy, in other words a PE may only deregister itself.
itself.
2.2.3 REGISTRATION_RESPONSE message 2.2.3 REGISTRATION_RESPONSE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x3 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operational Error (optional) | : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Member Selection Policy Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error Operational Error
This optional TLV parameter is included if an error occured during This optional TLV parameter is included if an error or a selection
the registration process. If the registration was sucessful this policy override occured during the registration process. The cause
parameter is not included. code carried in this TLV will indicate to the registering PE whether
the registration is rejected or accepted with a warning (e.g., policy
overruled). If the registration was sucessful and there is no
warning this parameter is not included.
Member Selection Policy
This optional TLV parameter is included if the ENRP has overridden
the member selection policy of the registering PE. The new policy is
indicated in this parameter. See Section 4.3? of [6] for more
details on policy override during registration.
2.2.4 DEREGISTRATION_RESPONSE message 2.2.4 DEREGISTRATION_RESPONSE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operational Error (optional) | : Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operational Error Operational Error
This optional TLV parameter is included if an error occured during This optional TLV parameter is included if an error occured during
the deregistration process. If the deregistration was sucessful this the deregistration process. If the deregistration was sucessful this
parameter is not included. parameter is not included.
2.2.5 NAME_RESOLUTION message 2.2.5 NAME_RESOLUTION message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x5 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a ENRP server via an SCTP association to This message is sent to a ENRP server to request translation of the
request translation of the Pool Handle to a list of Pool Elements. Pool Handle to a list of Pool Elements. If sent from a PE the SCTP
association used for registration SHOULD be used.
2.2.6 NAME_RESOLUTION_RESPONSE message 2.2.6 NAME_RESOLUTION_RESPONSE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x6 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x6 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy : : Overall PE Selection Policy (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter 1 : : Pool Element Parameter 1 (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter N : : Pool Element Parameter N (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Overall PE Selection Policy: Overall PE Selection Policy:
This is a PE selection policy parameter. Indicates the overall This TLV is a PE selection policy parameter and can be present when
selection policy of the pool. If not present, round-robin is the response is positive. It indicates the overall selection policy
assumed. of the pool. If not present, round-robin is assumed. This TLV is
not present when the response is negative (i.e., a rejection).
Note, any load policy parameter inside the Pool Element Parameter (if Note, any load policy parameter inside the Pool Element Parameter (if
present) MUST be ignored, and MUST NOT be used to determine the present) MUST be ignored, and MUST NOT be used to determine the
overall pool policy. overall pool policy.
2.2.7 NAME_UNKNOWN message Pool Element Parameters
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 When the response is positive, an array of PE TLVs are included,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ indicating the current PEs and their information in the named pool.
| Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | In a positive response, at least one PE TLV MUST be present. When
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the response is negative, no PE TLVs are included.
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is returned by the ENRP server to indicate that the Operational Error
requested Pool Handle hold no registered PE's.
2.2.8 ENDPOINT_KEEP_ALIVE message The presence of this TLV indicates that the response is negative
(i.e., the name resolution request was rejected by the ENRP server).
The cause code in this TLV (if present) will indicate the reason the
name resolution request was rejected (e.g., the requested pool handle
was not found).
2.2.7 ENDPOINT_KEEP_ALIVE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a PE by the ENRP server has a "health" check. This message is sent to a PE by the ENRP server has a "health" check.
If the transport level Heart Beat mechanism is insufficient (usually If the transport level Heart Beat mechanism is insufficient (usually
this means that time outs are set for too long or heartbeats are not this means that time outs are set for too long or heartbeats are not
frequent enough), this adds heartbeat messages with the goal of frequent enough), this adds heartbeat messages with the goal of
determining health status in a more timely fashion. determining health status in a more timely fashion.
2.2.9 ENDPOINT_KEEP_ALIVE_ACK message 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x9 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier Parameter | : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by the PE to the ENRP server has an This message is sent by the PE to the ENRP server has an
acknowledgment to the ENDPOINT_KEEP_ALIVE message. acknowledgment to the ENDPOINT_KEEP_ALIVE message.
2.2.10 ENDPOINT_UNREACHABLE message 2.2.9 ENDPOINT_UNREACHABLE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Identifier Parameter | : PE Identifier Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PE or PU will send this message to an ENRP server to report the A PE or PU will send this message to an ENRP server to report the
unreachability of the specified PE. unreachability of the specified PE.
2.2.11 SERVER_HUNT message 2.2.10 SERVER_ANNOUNCE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ..... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Transport param #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is used by either a PE or PU to request service. It is This message is sent by an ENRP server such that PUs and PEs know the
sent on the ENRP client channel. transport layer information necessary to connect to the ENRP server.
The transport parameters are optional and only TCP and SCTP transport
parameters are allowed.
2.2.12 SERVER_HUNT_RESPONSE message 2.2.11 COOKIE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0c |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is used by a ENRP server to respond to a PU or PE. It This message is sent by a PE to a PU. It may only be sent when a
is sent over a specific SCTP association which is established using control channel exists between the PE and PU.
the IP address and Port number received by the ENRP server in the
respective Server Hunt message that this message is in response to.
2.2.13 COOKIE message 2.2.12 COOKIE_ECHO message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0d |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0c |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter : : Cookie Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by a PE to a PU. This message is sent by a PU to a PE in case of a failover. The
Cookie Parameter is one received latest from the failed PE.
2.2.14 COOKIE_ECHO message 2.2.13 BUSINESS_CARD message
This message is sent by a PU to a PE or from a PE to a PU. This
parameter MUST NOT be sent if a control channel does NOT exists
between the PE and PU.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0e |0|0|0|0|0|0|0|0| Message Length | | Type = 0xd |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: .. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter-N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent by a PU to a PE in case of a failover. The The sender of this message lists both the Pool that the sender
Cookie Parameter is one received latest from the failed PE. belongs to and a prefered list of failover candidates.
2.2.14 PEER_ERROR message
This message is used to report an operation error.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xe |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. Procedures 3. Procedures
This section will focus on the methods and procedures used by an This section will focus on the methods and procedures used by an
internal ASAP endpoint. Appropriate timers and recovery actions for internal ASAP endpoint. Appropriate timers and recovery actions for
failure detection and management are also discussed. failure detection and management are also discussed.
3.1 Registration 3.1 Registration
When a PE wishes to join its server pool it MUST use the procedures When a PE wishes to join its server pool it MUST use the procedures
skipping to change at page 17, line 38 skipping to change at page 18, line 38
3.3 Name resolution 3.3 Name resolution
At any time a PE or PU may wish to resolve a name. This usually will At any time a PE or PU may wish to resolve a name. This usually will
occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or
requests a cache population (Section 4.3) but may occur for other requests a cache population (Section 4.3) but may occur for other
reasons (e.g. the internal ASAP PE wishes to know its peers for reasons (e.g. the internal ASAP PE wishes to know its peers for
sending a message to all of them). When an Endpoint (PE or PU) sending a message to all of them). When an Endpoint (PE or PU)
wishes to resolve a name it MUST take the following actions: wishes to resolve a name it MUST take the following actions:
NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool
Handle to be resolved. z Handle to be resolved.
NR2) If the endpoint does not have a Home ENRP server start the ENRP NR2) If the endpoint does not have a Home ENRP server start the ENRP
Server Hunt procedures specified in Section 3.6 to obtain one. Server Hunt procedures specified in Section 3.6 to obtain one.
Otherwise proceed to step NR3. Otherwise proceed to step NR3.
NR3) Send the NAME_RESOLUTION message to the Home ENRP server using NR3) Send the NAME_RESOLUTION message to the Home ENRP server using
SCTP. SCTP.
NR4) Start a T1-ENRPrequest timer. NR4) Start a T1-ENRPrequest timer.
If the T1-ENRPrequest timer expires before receiving a response If the T1-ENRPrequest timer expires before receiving a response
message, or a SEND.FAILURE notification is received from the SCTP message, or a SEND.FAILURE notification is received from the SCTP
layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see
Section 3.6) in an attempt to get service from a different ENRP Section 3.6) in an attempt to get service from a different ENRP
server. After establishing a new Home ENRP server the ASAP endpoint server. After establishing a new Home ENRP server the ASAP endpoint
SHOULD restart the name resolution procedure. SHOULD restart the name resolution procedure.
At the reception of the response message (either a At the reception of the response message (i.e., a
NAME_RESOLUTION_RESPONSE or NAME_UNKNOWN) the endpoint MUST stop its NAME_RESOLUTION_RESPONSE) the endpoint MUST stop its T1-ENRPrequest
T1-ENRPrequest timer. After stopping the T1 timer the endpoint timer. After stopping the T1 timer the endpoint SHOULD process the
SHOULD process the name response as appropriate (e.g. populate a name response as appropriate (e.g. populate a local cache, give the
local cache, give the response to the ASAP user, and/or use the response to the ASAP user, and/or use the response to send the ASAP
response to send the ASAP users message). users message).
Note that some ASAP endpoints MAY use a cache to minimize the number Note that some ASAP endpoints MAY use a cache to minimize the number
of name resolutions made. If such a cache is used it SHOULD: of name resolutions made. If such a cache is used it SHOULD:
C1) Be consulted before requesting a name resolution. C1) Be consulted before requesting a name resolution.
C2) Have a stale timeout time associated with the cache so that even C2) Have a stale timeout time associated with the cache so that even
in the event of a cache-hit, if the cache is "stale" it will cause in the event of a cache-hit, if the cache is "stale" it will cause
a new name_resolution to be issued to update the cache. a new name_resolution to be issued to update the cache.
C3) In the case of a "stale" cache the implementation may in parallel C3) In the case of a "stale" cache the implementation may in parallel
request an update and answer the request or block the user and request an update and answer the request or block the user and
wait for an updated cache before proceeding with the users wait for an updated cache before proceeding with the users
request. request.
C4) If the cache is NOT stale, the endpoint SHOULD NOT make a C4) If the cache is NOT stale, the endpoint SHOULD NOT make a
name_resolution request but instead return the entry from the name_resolution request but instead use the entry from the cache.
cache.
3.4 Endpoint keep alive 3.4 Endpoint keep alive
Periodically an ENRP server may choose to "audit" a PE. It does this Periodically an ENRP server may choose to "audit" a PE. It does this
by sending a ENDPOINT_KEEP_ALIVE message ( Section 2.2.8). Upon by sending a ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). Upon
reception of an ENDPOINT_KEEP_ALIVE message the following actions reception of an ENDPOINT_KEEP_ALIVE message the following actions
MUST be taken: MUST be taken:
KA1) The PE must verify that the Pool Handle is correct and matches KA1) The PE must verify that the Pool Handle is correct and matches
the Pool Handle sent in its earlier Registration. If the Pool the Pool Handle sent in its earlier Registration. If the Pool
Handle does not match silently discard the message. Handle does not match silently discard the message.
KA2) Send a ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.9) by: KA2) Send a ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by:
KA2.1) Filling in the Pool Handle Parameter with the PE's Pool KA2.1) Filling in the Pool Handle Parameter with the PE's Pool
Handle. Handle.
KA2.2) Fill in the PE Identifier that was used with this PE for KA2.2) Fill in the PE Identifier that was used with this PE for
registration. registration.
KA2.3) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the KA2.3) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the
appropriate SCTP association for that ENRP server. appropriate SCTP association for that ENRP server.
KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the
new home ENRP server.
3.5 Reporting unreachable endpoints 3.5 Reporting unreachable endpoints
Occasionally an ASAP endpoint may realize that a PE is unreachable. Occasionally an ASAP endpoint may realize that a PE is unreachable.
This may occur by a specific SCTP error realized by the ASAP endpoint This may occur by a specific SCTP error realized by the ASAP endpoint
or via a ASAP user report via the Transport.Failure Primitive or via a ASAP user report via the Transport.Failure Primitive
(Section 4.9.2). In either case the ASAP endpoint SHOULD report the (Section 4.9.2). In either case the ASAP endpoint SHOULD report the
unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message to unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message to
its home ENRP server. The Endpoint should fill in the Pool Handle its home ENRP server. The Endpoint should fill in the Pool Handle
and PE identifier of the unreachable endpoint. The message MUST be and PE identifier of the unreachable endpoint. If the sender is a PE
sent via SCTP to the Endpoints Home ENRP server. the message MUST be sent via SCTP to the Endpoints Home ENRP server.
Note: when processing a Transport.Failure Primitive (Section 4.9.2)
the ASAP endpoint MUST NOT send a unreachable report unless the ASAP
endpoint as sent at least one message to the PE specified by the
primitive.
3.6 ENRP server hunt procedures 3.6 ENRP server hunt procedures
Each PU and PE manages a list of transport addresses of ENRP servers.
If the multicast capabilities are used an ENRP server MUST send
periodically every T6-Serverannounce a SERVER_ANNOUNE message
(Section 2.2.10) including all the transport addresses available for
ASAP communication to the multicast channel.
If a SERVER_ANNOUNCE message is received by a PU or PE it SHOULD
insert all new included transport address in its list of ENRP server
addresses and start a T7-ENRPoutdate timer for each address. For all
already known addresses the T7-ENRPoutdate timers MUST be restarted.
If no transport parameters are included in the SERVER_ANNOUNCE
message the source IP address and the IANA registered ASAP port
number are used instead. It is also assumed that the transport
protocol used is SCTP. If a T7-ENRP timer for a transport address
expires the corresponding address is deleted from the list of
transport addresses.
If no multicast capabilities are used each PU and PE MUST have a
configured list of transport addresses of ENRP servers.
At its startup, or when it fails to send to (i.e., timed-out on a At its startup, or when it fails to send to (i.e., timed-out on a
service request) with its current home ENRP server, a PE or PU shall service request) with its current home ENRP server, a PE or PU shall
initiate the following home ENRP server hunt procedure to find a new establish its Home ENRP server, i.e. setup a TCP connection or SCTP
home server. association with an ENRP server.
SH1) The PE or PU shall send a SERVER_HUNT message (Section 2.2.11) To establish a new association or connection the following rules MUST
over the ENRP client channel. If the client channel is a multi- be followed:
cast destination only one message is needed. If the client
channel is a set of uni-cast addresses then a message SHOULD be
sent to no more than three ENRP server unicast address. A
Endpoint MUST NOT send to more than three at any single time.
SH2) The Endpoint shall start a T5-Serverhunt timer. SH1) The PE or PU SHOULD try to establish an association or
connection with no more than three ENRP server addresses. An
endpoint MUST NOT try to establish more than three association or
connections at any single time.
SH3) If the Endpoint receives a SERVER_HUNT_RESPONSE message the SH2) The endpoint shall start a T5-Serverhunt timer.
endpoint MUST stop its T5-Serverhunt timer. The Endpoint SHOULD
also reset the T5-Serverhunt value to its initial value and then
proceed to step SH5.
SH4) If the T5-Serverhunt timer expires the following should be SH3) If the endpoint establishes an association or connection it MUST
stop its T5-Serverhunt timer. The Endpoint SHOULD also reset the
T5-Serverhunt value to its initial value and then proceed to step
SH6.
SH4) If an association or connection establishment fails the endpoint
SHOULD try to establish an association or connection by using a
different transport address.
SH5) If the T5-Serverhunt timer expires the following should be
performed: performed:
SH4.1) The endpoint MUST double the value of the T5-Serverhunt SH5.1) The endpoint MUST double the value of the T5-Serverhunt
timer. timer.
SH4.2) The endpoint SHOULD Repeat sending a server hunt message by SH5.2) The endpoint SHOULD stop the establishment of associations
proceeding to step SH1. Note that if the server hunt procedure and connections.
are using a unicast channel the endpoint SHOULD attempt to
select a different set of ENRP servers to send the SERVER_HUNT
message to.
SH5) The PE or PU shall pick one of the ENRP servers that have SH5.2) The endpoint SHOULD repeat trying to establish an
responded as its new home ENRP server, and send all its subsequent association or connection by proceeding to step SH1. It SHOULD
the namespace service requests to this new home ENRP server. attempt to select a different set of transport addresses to
connect to.
Upon the reception of the SERVER_HUNT message, an ENRP server shall SH6) The PE or PU shall pick one of the ENRP servers that it was able
always reply to the PE with a SERVER_HUNT_RESPONSE message. to establish an association or connection with, and send all its
subsequent the namespace service requests to this new home ENRP
server.
3.7 Handle ASAP to ENRP Communication Failures 3.7 Handle ASAP to ENRP Communication Failures
Three types of failure may occur when the ASAP endpoint at an Three types of failure may occur when the ASAP endpoint at an
endpoint tries to communicate with the ENRP server: endpoint tries to communicate with the ENRP server:
A) SCTP send failure A) SCTP send failure
B) T1-ENRPrequest timer expiration B) T1-ENRPrequest timer expiration
C) Registration failure C) Registration failure
Registration failure is discussed in Section 3.1 Registration failure is discussed in Section 3.1
3.7.1 SCTP Send Failure 3.7.1 SCTP Send Failure
This indicates that the SCTP layer failed to deliver a message sent This indicates that the SCTP layer failed to deliver a message sent
to the ENRP server. In other words, the ENRP server is currently to the ENRP server. In other words, the ENRP server is currently
skipping to change at page 22, line 5 skipping to change at page 23, line 5
in a Cookie Echo message to the new PE. The upper layer may be in a Cookie Echo message to the new PE. The upper layer may be
involved in the failover procedure. involved in the failover procedure.
This cookie mechanism can be used as a simple method for state This cookie mechanism can be used as a simple method for state
sharing. Therefore a cookie should be signed by the sending PE and sharing. Therefore a cookie should be signed by the sending PE and
this should be verified by the receiving PE. The details of this are this should be verified by the receiving PE. The details of this are
out of scope of this document. It is only important that the PU out of scope of this document. It is only important that the PU
stores always the last received Cookie Parameter and sends that back stores always the last received Cookie Parameter and sends that back
unmodified in case of a PE failure. unmodified in case of a PE failure.
3.9 Business Card handling procedures
When communication begins between a PU and a PE (i.e. the first
message is sent from the PU to the PE) the ASAP layer in the PU
SHOULD send a Business card IF the sender is also registered as a PE.
A PE may also send back to a PU a business card as well. A Bussiness
card MUST NOT be sent if a control channel does NOT exist between the
PU and PE. After communication as been established between a PE and
PU at any time either entity may update its failover distribution by
sending a new Business Card.
The business card serves two purposes (for both endpoints PU and PE).
First it lists the endpoints pool handle. For a PU contacting a PE
this is essential so that the PE may also gain the full benefits of
ASAP if the PU is also a PE. Secondly the business card tells the
receiver a failover order that is recommended to follow. This may
facilitate rendouvous between PE's as well as some control of load
redistribution upon the failure of any given PE.
Upon receipt of a Business Card Message (see Section 2.2.13) the
receiver SHOULD:
BC1) Unpack the business card, and if no entry exists in the
translation cache and one exists, populate the new Pool Handle
into the cache and request a NAME.RESOLUTION of the pool handle.
BC2) Create a list for this PE of prefered failover order so that in
the event of a failure the prefered list will be used to guide the
ASAP endpoint in the selection of an alternate PE.
4. The ASAP Interfaces 4. The ASAP Interfaces
This chapter will focus primarily on the primitives and notifications This chapter will focus primarily on the primitives and notifications
that form the interface between the ASAP-user and ASAP and that that form the interface between the ASAP-user and ASAP and that
between ASAP and its lower layer transport protocol (e.g., SCTP). between ASAP and its lower layer transport protocol (e.g., SCTP).
An ASAP User passes primitives to the ASAP sub-layer to request An ASAP User passes primitives to the ASAP sub-layer to request
certain actions. Upon the completion of those actions or upon the certain actions. Upon the completion of those actions or upon the
detection of certain events, the ASAP will notify the ASAP user. detection of certain events, the ASAP will notify the ASAP user.
skipping to change at page 32, line 19 skipping to change at page 34, line 19
4.9.2 Transport.Failure Primitive 4.9.2 Transport.Failure Primitive
Format: transport.failure(Pool-Handle, Transport-address) Format: transport.failure(Pool-Handle, Transport-address)
If an external user encounters a failure in sending to a PE and is If an external user encounters a failure in sending to a PE and is
NOT using ASAP it can use this primitive to report the failure to the NOT using ASAP it can use this primitive to report the failure to the
ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home"
ENRP server in response to this primitive. Note ASAP SHOULD NOT send ENRP server in response to this primitive. Note ASAP SHOULD NOT send
a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous
request to the translate.request() primitive. request to send data to the PE.
5. Variables, Timers, and Thresholds 5. Variables, Timers, and Thresholds
The following is a summary of the variables, timers, and pre-set The following is a summary of the variables, timers, and pre-set
protocol constants used in ASAP. protocol constants used in ASAP.
5.1 Timers 5.1 Timers
T1-ENRPrequest - A timer started when a request is sent by ASAP to T1-ENRPrequest - A timer started when a request is sent by ASAP to
the ENRP server (providing application information is queued). the ENRP server (providing application information is queued).
skipping to change at page 33, line 28 skipping to change at page 35, line 28
T3-deregistration - A timer started when sending a deregistration T3-deregistration - A timer started when sending a deregistration
request to the home ENRP server, normally set to 30 seconds. request to the home ENRP server, normally set to 30 seconds.
T4-reregistration - This timer is started after successful T4-reregistration - This timer is started after successful
registration into the ASAP name space and is used to cause a re- registration into the ASAP name space and is used to cause a re-
registration at a periodic interval. This timer is normally set registration at a periodic interval. This timer is normally set
to 10 minutes or 20 seconds less than the Life Timer parameter to 10 minutes or 20 seconds less than the Life Timer parameter
used in the registration request (whichever is less). used in the registration request (whichever is less).
T5-Serverhunt - This timer is used nto during the ENRP server hunt T5-Serverhunt - This timer is used during the ENRP server hunt
procedure and is normally set to 120 seconds. procedure and is normally set to 120 seconds.
T6-Serverannounce - This timer gives the time between the sending of
consequetive SERVER_ANNOUNCE messages. It is normally set to 1
second.
T7-ENRPoutdate - This timer gives the time a server announcement is
valid. It is normally set to 5 seconds.
5.2 Thresholds and Variables 5.2 Thresholds and Variables
max-reg-attempt - The maximum number of registration attempts to be max-reg-attempt - The maximum number of registration attempts to be
made before a server hunt is issued. made before a server hunt is issued.
max-request-retransmit - The maximum number of attempts to be made max-request-retransmit - The maximum number of attempts to be made
when requesting information from the local ENRP server before a when requesting information from the local ENRP server before a
server hunt is issued. server hunt is issued.
stale.cache.value - A threshold variable that indicates how long a stale.cache.value - A threshold variable that indicates how long a
skipping to change at page 35, line 7 skipping to change at page 37, line 7
response, then they are free to make that choice. However, if the response, then they are free to make that choice. However, if the
end user does require security, they are guaranteed to get it due to end user does require security, they are guaranteed to get it due to
the requirement for security support for the ENRP server. It is also the requirement for security support for the ENRP server. It is also
possible for the ENRP server to reject an unsecured request from the possible for the ENRP server to reject an unsecured request from the
user due to its security policy in the case that it requires user due to its security policy in the case that it requires
enforcement of strong security. But this will be determined by the enforcement of strong security. But this will be determined by the
security requirements of the individual network design. security requirements of the individual network design.
7. Acknowledgments 7. Acknowledgments
The authors wish to thank John Loughney, Lyndon Ong, and many others The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon
for their invaluable comments. Ong, and many others for their invaluable comments.
Normative References Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
skipping to change at page 37, line 47 skipping to change at page 39, line 47
Phone: +1-607-273-0724 Phone: +1-607-273-0724
EMail: maureen.stillman@nokia.com EMail: maureen.stillman@nokia.com
Michael Tuexen Michael Tuexen
Siemens AG Siemens AG
ICN WN CC SE 7 ICN WN CC SE 7
D-81359 Munich D-81359 Munich
Germany Germany
Phone: +49 89 722 47210 Phone: +49 89 722 47210
EMail: Michael.Tuexen@icn.siemens.de EMail: Michael.Tuexen@siemens.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/