Persistent Objects Working Group V. Cerf Internet Draft I. Stewart P. Vixie Intended status: Standards Track K. Almeroth B. Billadeau Expires: 07 May 2009 07 November 2008 Discovery Protocol for Directory of Persistent Objects draft-irtf-powg-dpdpo-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on Feb 7 2009. Abstract This document describes a discovery protocol and basic design for a directory of persistent objects. Such a directory could have far reaching applications, however this document will concentrate on one application as proof of concept, first fully describing the problem and then explaining the proposed solution. V. Cerf, et al. Expires Feb 07, 2009 [Page 1] Internet-Draft Directory of Persistent Objects December 2008 Despite the positive impact of Classless Inter-Domain Routing (CIDR) [1], the addition of new protocols and their associated tables have consumed Internet Message Processor (router) memory beyond acceptable limits. This document defines how a "Discovery Protocol" and the definition of a structure for a "Directory of Persistent Objects" could provide a solution to the aforementioned problem. Table of Contents 1. Introduction...................................................3 2. DP-DPO vs. competing solutions.................................5 2.1. DP-DPO vs. Embedded RP (Rendezvous Point).................5 2.2. DP-DPO vs. Protocol based discovery.......................6 3. Conventions used in this document..............................6 4. Overview of DP-DPO.............................................6 4.1. The Discovery Protocol (DP)...............................6 4.2. The Directory of Persistent Objects (DPO).................7 5. The DP-DPO's dynamic scale.....................................8 5.1. DP-DPO ECHELON Map........................................8 5.2. DPO Structure.............................................9 6. Query Protocol (QP) format.....................................9 6.1. Query Protocol (QP) Map..................................10 7. Discovery Protocol Low Level Commands.........................10 7.1. CMD Map..................................................10 7.2. CMD Flags................................................10 7.3. CMD Commands functions...................................10 7.4. Secure mode commands.....................................11 7.5. Client side and server side translation examples.........11 7.5.1. Object instantiation pseudo code and high level functions..................................................11 7.5.2. Server side pseudo code matching above functions....11 7.5.3. Query/Answer data flow..............................12 8. Secure mode operation at object...............................12 9. Answer Protocol (AP) Format...................................13 9.1. Array packing and unpacking..............................13 9.2. Format map for Answer Protocol...........................13 10. Servers......................................................14 10.1. Servers Diagram.........................................15 11. Financial considerations.....................................15 12. Formal Syntax and Terminology................................15 12.1. Syntax..................................................15 12.2. Terminology.............................................16 13. Security Considerations......................................16 14. IANA Considerations..........................................16 15. Conclusions..................................................16 16. Acknowledgments..............................................17 V. Cerf, et al. Expires Feb 07, 2009 [Page 2] Internet-Draft Directory of Persistent Objects December 2008 17. References...................................................17 17.1. Normative References....................................17 17.2. Informative References..................................18 1. Introduction Internet traffic depends on a complex association of previously recorded data objects. This document defines an association mechanism that provides an extensible and scalable protocol to access persistent data. The mechanism is called the Discovery Protocol for a Directory of Persistent Objects, which is abbreviated as DP-DPO. Two examples of the vital role played by persistent data objects are the Domain Name System and the function of Internet message processors (routers). o The discovery of domain addresses associates top-level domain names with their IP addresses [2]. These addresses are associated with domain name servers that associate all hosts within their structure. The persistence of the top-level domains IP association creates a mechanism to resolve domain names to addresses. And the persistent object data in the DNS system allows for a host to be pointed to a server for further resolution. o In order for Internet message processors to handle packets, they gain the necessary rules through an exchange with other Internet message processors using protocols like BGP [3]. Persistent protocol numbers registered with IANA identify these protocols and the Message Processors themselves [4] and have persistent records of their neighbor Internet Message Processors (routers). They use this persistent data as the basis of their protocols to build dynamic route information. As internetworking infrastructure grows, Internet message processors handle more types of information. These messages are processed according to rule sets established that are invariably rooted in persistent data. By using persistent neighbor addresses [3], modern routers exchange large numbers of dynamic routes stored in random access memory tables. Comparing or hashing incoming packets to these tables uses resources (central processing unit cycles). The maintainers of these routing devices tend to measure performance in packets processed per second rather than total throughput because of the resources consumed. The growing amount of rule sets and policies using protocols is contributing to an exponential increase in central processing V. Cerf, et al. Expires Feb 07, 2009 [Page 3] Internet-Draft Directory of Persistent Objects December 2008 resources consumed. Managers of these devices are understandably resistant to the adoption of additional tables that increase complexity. The management of the current tables has already become unwieldy. A good example of IT manager's resistance to add additional tables to their routing infrastructure is the lack of native support for MSDP [5] on the Internet2 [6]. o The Internet2 is one of the largest test beds for the next generation Internetworking protocols IPV6 [7]. o One of the areas of interest for Internet2 is the point-to- multipoint protocol for Anycast [8] and IP Multicast [9]. o Support for MSDP in IPV6 on the Internet2 was not undertaken due to scalability and security concerns. o The Internet2 has no discovery mechanism for point-to-multipoint sources given native IPV6 operation. Providing an IPV6 compatible Discovery Protocol that could efficiently discover the sources for IP Anycast and IP Multicast would be a good initial use for the Directory of Persistent Objects. Internet Message Processors could retain (cache) the more frequently used persistent objects, hence increasing performance without maintaining a separate table for MSDP. o This paper will show how a persistent object database could solve the discovery problem of IP Multicast for Internet2/IPV6. o The Directory of Persistent Objects has many applications that are beyond the scope of this document. o Implementing a scalable discovery mechanism for sources will provide ample proof of DP-DPO concept and value. o The DP-DPO model builds on current technologies to maximize efficiencies in regards to development and to take advantage of future improvements in underlying technologies. V. Cerf, et al. Expires Feb 07, 2009 [Page 4] Internet-Draft Directory of Persistent Objects December 2008 2. DP-DPO vs. competing solutions 2.1. DP-DPO vs. Embedded RP (Rendezvous Point) o Embedding the RP in the IP address makes IGMPV3 a requirement when joining a group. IGMPV3 [10] is not required when using DP-DPO (as a source discovery protocol). DP-DPO is compatible with IGMPV2, hence it can be used with far more infrastructure. o Embedded RP cannot handle multiple sources. DP-DPO has unlimited sources. This ability will accommodate redundant RP's in PIM [11], and in the future "RP-less" distribution of point-to-multipoint data. o Embedded RP makes IPV6 a requirement as no address space exists to embed a source in IPV4. In contrast DP-DPO works on IPV4, offering seamless (and configuration-less) switch to, and encapsulation by, IPV6. o Embedded RP requires the end user to do a DNS-look-up and HTTP- query or accomplish an SDR [12] session. DP-DPO makes no requirements or demands on the resources of end users. o Embedding the discovered source into the IP packets adds complexity and latency to end user programs. Furthermore, the end user discovery must be preformed each time, so the latency is compounded by frequent requests to join groups ("channel surfing"). DP-DPO, which is extensible to other applications in the future, will perform its first query in as little as 20MS (or less, for object creation) and subsequent queries are automatically cached in the object (the object life is configurable). o Socket and infrastructure support for (s,g) joins is not uniform across OS's. For example: Despite the Windows support for IGMPV3, Microsoft NSC files (Multicast Station Files) have no source (or RP) fields. This means that the Windows Media Player has no apparent-sure mechanism to find the RP and therefore would be incompatible with Embedded RP. DP-DPO is a solution that includes the Microsoft family of products without modification of its codes. o Embedded RP contributes to processing overhead in Internet Message Processors. Each Multicast packet must be examined for the embedded source. DP-DPO examines the IGMP request and locates the source, once found the object remains for a period determined by the operator. DP-DPO requires no packet inspection. V. Cerf, et al. Expires Feb 07, 2009 [Page 5] Internet-Draft Directory of Persistent Objects December 2008 2.2. DP-DPO vs. Protocol based discovery DP-DPO when used as a discovery mechanism has little impact on router memory. DP-DPO as a discovery protocol offloads the router tables for discovery protocols. Also, with DP-DPO popular groups (groups that already have data flowing at the router) are joined more efficiently as no discovery is needed because the source is known. Using DP-DPO will allow routing infrastructure a seamless and scalable integration path from MSDP and other "neighbor" based protocols. MSDP sources can be mapped to DP-DPO sources, furthering the IPV6 compatibility with IPV4 and offloading the router maintained source discovery process. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 4. Overview of DP-DPO DP-DPO consists of two main sections: 4.1. The Discovery Protocol (DP) In order to be useful, a Directory of Persistent Objects needs a method to instantiate the object for access by a programming language. Because these objects are mounted over the Public Internet the amount of time involved in this process is of critical importance. A connectionless protocol is the most efficient way to communicate using Public Infrastructure, hence the use of UDP as a test bed for the initial operation of the Discovery Protocol. The Discovery Protocol makes no use of the domain name system, as this would contribute to latency. Instead the discovery protocol submits its query - and the response is directed to well-known address for future use, which are cached by the Discovery Protocol application. The Discovery Protocol server uses round robin Intelligent PRE PROCESS switching to allocate the servers and allow for scale. V. Cerf, et al. Expires Feb 07, 2009 [Page 6] Internet-Draft Directory of Persistent Objects December 2008 The Discovery protocol has a separate Query Protocol definition and an Answer Protocol definition. Both the Query Protocol and the Answer Protocol are dynamic and based on levels of operation that are called ECHELONS. The Levels of operation (ECHELONS) provide extensibility to the Persistent Object data and are logarithmic in the way they scale. The logarithmic addressing scheme can accommodate future expansion without modification to the source code. o The Discovery Protocol (DP) uses the UDP model for transport. o No requirement will be made of IANA to assign the DP its own protocol number. UDP port prioritization and/or deeper inspection can be used for QOS and ease of identification (see IANA Considerations). o After instantiation, the first use of the DP returns a well-known IP Address of a geographically efficient server for subsequent access. o The DP server(s) use round robin Intelligent PRE PROCESS switching. o The DP has a separate format for Query Protocol (QP) and Answer Protocol (AP). o Users of the DP-DPO instantiate an object with parameters, ECHELON, id and key. o DP-DPO can push any or all new parameters, ECHELON, id and key to the object. o Multiple unlimited DP-DPO objects can be instantiated. 4.2. The Directory of Persistent Objects (DPO) The DPO's data engine is connected to a edge triggered DP-DPO message server. The ECHELON (EC) at which it operates determines the DPO size. The DPO consists of Public data and private data. The private data is encrypted and can only be accessed by individual record. Public data from the current ECHELON of the DPO can be queried in such a way that results in an object array being returned in the DP- DPO's Answer Protocol (AP). The Discovery Protocol (DP) has a default limit that is adjusted to the number of records that the AP can return. V. Cerf, et al. Expires Feb 07, 2009 [Page 7] Internet-Draft Directory of Persistent Objects December 2008 o The DPO's query server could take advantage of considerable work already preformed in these fields. o The DPO connects to a host program or Internet Message Processor using the Discovery Protocol (DP) o The DP uses an underlying transport (UDP) to communicate the instantiated objects desire to interact with the DPO o The DPO is extensible by a simple logarithmic scale in which all aspects of the object data and discovery query are scaled. o The DPO consists of private fields and public fields o Only the DPO's public fields can be queried for pattern match across multiple records. o Only ECHELON Administrators can query multiple DPO private encrypted fields over secure connection. 5. The DP-DPO's dynamic scale. The DPO size and number of fields scales depending on the current ECHELON. 5.1. DP-DPO ECHELON Map In the figure 1 below - ECHELON 0 has one 8 bit ECHELON field with a value of 0, one 256 bit ID field, two 256 bit Public data fields, two 256 bit Private Data Fields, and one 128 bit Private Key Field. V. Cerf, et al. Expires Feb 07, 2009 [Page 8] Internet-Draft Directory of Persistent Objects December 2008 8 bit ID Private Public Private Key ECHELON Field Fields Fields Field +-------------------------------------------------------------+ 0x00| 256 bits | 2x 256 bits | 2x 256 bits | 128 bits| 0x01| 512 bits | 4x 512 bits | 4x 512 bits | 256 bits| 0x02| 1024 bits | 8x 1024 bits | 8x 1024 bits | 512 bits| ... | 2^(EC+8) | 2^(EC+1)x 2^(EC+8)| 2^(EC+1)x 2^(EC+8)| 2^(EC+7)| 0xFF| 2^(263) | 2^(256)x 2^(263) | 2^(256)x 2^(263) | 2^(262) | +-------------------------------------------------------------+ Figure 1 5.2. DPO Structure DPO id's are unique and the size is determined by the ECHELON Naming conventions for DPO fields are as follows: Private Fields PRI[x] Public Fields PUB[x] Where x represents the field number in the corresponding ECHELON Other Fields available to ECHELON Administrators only are: ECHELON ID PRIVKEY 6. Query Protocol (QP) format o The QP has ECHLEONS that logarithmically scale the QP and associated DPO. o The QP uses UDP as its transport V. Cerf, et al. Expires Feb 07, 2009 [Page 9] Internet-Draft Directory of Persistent Objects December 2008 6.1. Query Protocol (QP) Map | ECHELON | ID FIELD | CMD | LOQ | QUERY | | 8 bits | EC+1 * 256 |16 bits |-16 bits-| (Variable) | Size in bytes in LOQ. Figure 2 ECHELON = The Level of the DPO ID FIELD = The ID of the Persistent Object (Depends on EC Level) 7. Discovery Protocol Low Level Commands 7.1. CMD Map 16 Bits |0123456701234567| | || 7.2. CMD Flags CMD Flag 0 = First Instantiation. New server address is appended to end of array with type 2. (automated) CMD Flag 1 = Secure Operation. Encrypted key is appended to array. CMD Flag 2-7 = Reserved. 7.3. CMD Commands functions 0 = Return Persistent Data (1st field in Public). 2 = Return all Persistent Data in Record. 3 = Base Public Sources Query - put an IP in QUERRY to return sources, FIELD PRI01 searched and PRIO2 returned in array. 4 = New Server IP. V. Cerf, et al. Expires Feb 07, 2009 [Page 10] Internet-Draft Directory of Persistent Objects December 2008 5 through 254 are reserved. 7.4. Secure mode commands Secure mode operation appends a field of private data to the Answer Protocol (see Array Packing and Unpacking, Element type 3). This field contains the encryption key, which has itself been encrypted using the encryption key. The instantiated object has knowledge of the encryption (decode) key therefore; once the returned encryption key is decrypted, the keys can be compared. Security is heightened because an attacker has no knowledge of the unencrypted key. 7.5. Client side and server side translation examples 7.5.1. Object instantiation pseudo code and high level functions ** instantiate object DPO[x] = new DPO (EC); ** create object Error = DPO[x]->CreateDpoObject(id, [password],[flag]); The functions use the DP's CMD's to tells the object what to do. For example: *** Function A *** A[] = DPO[x]->GetPersistantData(PUB[[x]]); This query returns PUB[[x]] as an array from the DPO *** Function B *** A[] = DPO[x]->GetPublicData(querydata) This query returns multiple public fields found to match "querydata" as an array from the DPO 7.5.2. Server side pseudo code matching above functions *** Function A *** find DPO[ECHELON],DPO[Public field[s]] with DPO[ID] containing "id"; V. Cerf, et al. Expires Feb 07, 2009 [Page 11] Internet-Draft Directory of Persistent Objects December 2008 *** Function B *** find DPO[ECHELON], DPO[Public field[2]] with DPO[Public Field[1]] containing "querydata"; 7.5.3. Query/Answer data flow |--------| |--------| |--------| |--------| |--------------| | OBJECT | | OBJECT | | OBJECT | | OBJECT | | | |--------| |--------| |--------| |--------| | | | | | ^ | ^ | | | | | | | | | Data Engine | | | | | | | |---| | | | | | | | | | | | | | | | | | P | | <- Answer | v v v v | R | |--------------| |--------| |--------| |------| |--------| | E | ^ |UDP MSG | |UDP MSG | |UDPMSG| |UDP MSG | | | | |--------| |--------| |------| |--------| | P | | | ^ | ^ | | R | |--------------| | | | | | | O |<->| -> Query | | | | | | | C | | Processor | | + | + | | E | | | | | | | | S | | | | v v v | S | | v | |-----------------------------------| | O | | Data | | IP CLOUD |<->| R | | Distribution | |-----------------------------------| | | |--------------| |---| Figure 3 8. Secure mode operation at object Attack resistant functions for DPO objects are implemented by pushing a secure mode CMD onto the object. The validity of the data object is verified upon its return from the server. The server encrypts the V. Cerf, et al. Expires Feb 07, 2009 [Page 12] Internet-Draft Directory of Persistent Objects December 2008 encryption code (with its own key) and appends it to the fields returned by the query protocol. The object then decrypts the key and matches it to the well-known key already stored within the within the object. 9. Answer Protocol (AP) Format In the AP the server parses the query and checks to make sure the results contain no blank fields. Blank fields are not returned to the object hence efficiency is maximized. 9.1. Array packing and unpacking Arrays are packed in the following format: |Primer + Element Type|Element Size|Element | | 16 bits | EC+9 |variable| PRIMER 12 bits Element Type 4 bits Element Type 0 Public Field Element Type 1 Private Field Element Type 2 First instantiation Element Type 3 Security mode operation Element Type 4...15 reserved In order to double check the Array transfer when the array is decoded the Primer is checked for each Array element. At the end of the length of the data should be another Primer. If this condition proves false the packet is discarded and a retransmission request is queued. A counter is incremented for limiting the amount of retransmission requests. 9.2. Format map for Answer Protocol | ECHELON | ID FIELD |CMD | ARRAY| LOA | ARRAY | bits-> | --8-- | EC+1 * 256 |-16-| EC +2|- 128 -|DEPENDS ON LOA| Note: ARRAY and LOA includes appended fields V. Cerf, et al. Expires Feb 07, 2009 [Page 13] Internet-Draft Directory of Persistent Objects December 2008 10. Servers In order to scale efficiently, a custom configured PRE PROCESS switch front ends the servers that parse the Query Protocol. The servers are assigned using a round robin technique. DPO Propagation takes place by mirroring new additions and updates. Because data is persistent propagation is less critical than in highly dynamic data arrays. The stages of the processing order pictured from bottom up: 1. Persistent object instantiated. 2. DP Query constructed and send via IPV4 or IPV6. 3. PRE PROCESS SWICH identifies the ECHELON. 4. Base on ECHELON level the processing of the packet is assigned to server array. 5. Object data fetched from storage array. 6. DP-DPO Answer Protocol is constructed at server. 7. Data returned to object. V. Cerf, et al. Expires Feb 07, 2009 [Page 14] Internet-Draft Directory of Persistent Objects December 2008 10.1. Servers Diagram +---------------+ +---------------+ | Storage Array | >--> | Propagated | +---------------+ +---------------+ / | \ / | \ / | \ / | \ +------+ +------+ +------+ +------+ Servers->| EC00 | | EC00 | | EC00 | ... | EC01 | ... +------+ +------+ +------+ +------+ | | | | +-------------------------------+ | PRE PROCESSING SWITCH | +-------------------------------+ | +---------------------------+ | IPV4 / IPV6 | +---------------------------+ Figure 4 11. Financial considerations It is anticipated that as with the domain name service that there will be fees associated with the continued use of the DPO. These fees will cover the expenses associated with the maintenance of the DP servers and DPO databases. 12. Formal Syntax and Terminology 12.1. Syntax Commonly used grammar is BNF grammar defined in RFC-2234. Suggested wording. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234. V. Cerf, et al. Expires Feb 07, 2009 [Page 15] Internet-Draft Directory of Persistent Objects December 2008 12.2. Terminology DP = DPO Discovery Protocol for Directory of Persistent Objects DP = Discovery Protocol QP = Query Protocol AP = Answer Protocol DPO = Directory of Persistent Objects EC = ECHELON, the level of the Persistent Object 13. Security Considerations The DPO has private fields and public fields. The private fields are encrypted using AES encryption. The keys for these fields will be input through the use of secure hypertext servers. 14. IANA Considerations The Discovery Protocol is designed to function using UDP as its transport. In the opinion of the author(s), any hope for a protocol other than UDP is misplaced. For instance; even getting a new port number added to enough firewalls to allow universal adoption is a high barrier. In the opinion of the authors(s) asking network managers to upgrade the software in their firewalls to handle - a new transport protocol number - and rules for same - is beyond reason. For sake of optimizing quality of service and easy identification of DP-DPO traffic it would be helpful to have a distinct protocol number, but deeper inspection or port prioritizing can accomplish this goal without the assignment. It is suggested that a protocol number could be assigned and used optionally once the DP-DPO has proven its usefulness. 15. Conclusions By adding simple mechanisms for scale and proximity the DP-DPO can accomplish the reading of persistent data objects in as little as 20 milliseconds. The authors believe the protocol is extensible enough to allow for many new uses. The domain name system has served as a model of how persistent data can relieve Internet Message Processors of jobs that they cannot possibly complete at scale (the augmentation of the hosts file). The author(s) feel that the DP-DPO protocol can initially provide a solution for discovery of sources. The IPV6 development teams have been resisting the MSDP protocol as it adds to their random access memory tables. The MSDP protocol function could be replaced by a highly scalable DPO that would be easy to use, V. Cerf, et al. Expires Feb 07, 2009 [Page 16] Internet-Draft Directory of Persistent Objects December 2008 implement, and provide an automated cache for frequently accessed data. The author(s) feel that a scalable replacement mechanism for MSDP would provide welcome relief to the IPV6 community and provide a proving ground for the DP-DPO protocol and is future varied application. 16. Acknowledgments The Authors would like to acknowledge the work of the many members of the Internet community, who seek only to improve the quality of life for all individuals. This work is built upon their incredible diligence. 17. References 17.1. Normative References [1] [RFC 1519] V. Fuller Et al., " Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy" , September 1993 [2] [RFC 1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [4] [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [5] [Interdomain Multicast Routing] ISBN 0-201-74612-3 -5.7 "SA Storms Ramen and Rate Limiting". Brian Edwards, Leonard A. Giuliano, and Brian Wright [6] [Internet 2] May 7th, 1998 Juha Eskelin Department of Computer Science Helsinki University of Technology Juha.Eskelin@hut.fi [7] [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. V. Cerf, et al. Expires Feb 07, 2009 [Page 17] Internet-Draft Directory of Persistent Objects December 2008 [8] [RFC1546] Host Anycasting Service C. Partridge, T. Mendez, W. Milliken [9] [RFC 1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. 17.2. Informative References [10] [RFC 3376] Cain, et. al, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002 [11] [RFC 2362] D. Estrin et. al, "Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998 [12] [draft-ietf-mmusic-sap-00.txt] M Hadley, "SAP: Session Announcement Protocol", draft-ietf-mmusic-sap-00.txt, 19th Nov 1996 [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [14] [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002. [15] [IANA-AF] "Address Family Numbers", Reachable from http://www.iana.org/numbers.html V. Cerf, et al. Expires Feb 07, 2009 [Page 18] Internet-Draft Directory of Persistent Objects December 2008 Author's Addresses Cerf, Vinton G. Google 1818 Library St Suite 400 Reston VA 20190 Phone: 202-370-5637 Vint@[erase-this]google.com Stewart, Ian A. Worldcast 4125 Market #19, Ventura CA 93003 Phone: (805)289-1511 Email: ianastewart@[erase-this]worldcast.tv Full Copyright Statement Copyright (C) The IETF Trust (0000). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. V. Cerf, et al. Expires Feb 07, 2009 [Page 19] Internet-Draft Directory of Persistent Objects December 2008 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. V. Cerf, et al. Expires Feb 07, 2009 [Page 20]