Internet Emergency Preparedness Service

--- 1/draft-ietf-tsvwg-mlpp-that-works-03.txt	2006-03-02 22:12:52.000000000 +0100 +++ 2/draft-ietf-tsvwg-mlpp-that-works-04.txt	2006-03-02 22:12:52.000000000 +0100 @@ -1,21 +1,21 @@ Transport Working Group                                        F. Baker Internet-Draft                                                  J. Polk -Expires: August 13, 2006                                  Cisco Systems -                                                       February 9, 2006 +Intended status: Experimental                             Cisco Systems +Expires: August 31, 2006                              February 27, 2006 Implementing an Emergency Telecommunications Service for Real Time Services in the Internet Protocol Suite -                 draft-ietf-tsvwg-mlpp-that-works-03 +                 draft-ietf-tsvwg-mlpp-that-works-04 -Status of this Memo +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. @@ -24,108 +24,87 @@   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 August 13, 2006. +  This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of -  services require call preemption; others, call for call queuing or -   other mechanisms. The key requirement is to guarantee an elevated -  probability of call completion to an authorized user in time of -   crisis. - -  IEPS requires a Call Admission Control (CAC) procedure and a Per Hop -  Behavior for the data which meet the needs of this architecture. -  Such a CAC procedure and PHB is appropriate to any service that might -  use H.323 or SIP to set up real time sessions. These obviously -  include, but are not limited to, Voice and Video applications, -  although at this writing the community is mostly thinking about Voice -  on IP and many of the examples in the document are taken from that -  environment. - -  In a network where a call that is permitted initially and is not -  denied or rejected at a later time, call and capacity admission -  procedures performed only at the time of call setup may be -   sufficient. However, in a network where session status can be -  reviewed by the network and preempted or denied due to changes in -   routing (when the new routes lack capacity to carry calls switched to -   them) or changes in offered load (where higher precedence calls -   supersede existing calls), maintaining a continuing model of the -  status of the various calls is required. +  services require call preemption; others call for call queuing or +   other mechanisms. IEPS requires a Call Admission Control (CAC) +  procedure and a Per Hop Behavior for the data which meet the needs of +   this architecture. Such a CAC procedure and PHB is appropriate to +  any service that might use H.323 or SIP to set up real time sessions. +  The key requirement is to guarantee an elevated probability of call +  completion to an authorized user in time of crisis. -  Although this document primarily discusses requirements for the US -   Government and NATO, the architecture described here is applicable -  outside these two organizations. +  This document primarily discusses supporting ETS in the context of +   the US Government and NATO, because it focuses on the MLPP and GETS +  standards. The architectures described here are applicable beyond +  these organizations. Table of Contents 1. Overview of the Internet Emergency Preference Service problem and proposed solutions. . . . . . . . . . . . . . . . 4      1.1.  Emergency Telecommunications Services. . . . . . . . . . 4        1.1.1.  Multi-Level Preemption and Precedence. . . . . . . . 5        1.1.2.  Government Emergency Telecommunications Service. . . 7      1.2.  Definition of Call Admission. . . . . . . . . . . . . . . 7 -     1.3.  Assumptions about the Network. . . . . . . . . . . . . . 7 +     1.3.  Assumptions about the Network. . . . . . . . . . . . . . 8      1.4.  Assumptions about application behavior. . . . . . . . . . 8 -     1.5.  Desired Characteristics in an Internet Environment. . . . 9 -     1.6.  The use of bandwidth as a solution for QoS. . . . . . . . 10 +    1.5.  Desired Characteristics in an Internet Environment. . . . 10 +    1.6.  The use of bandwidth as a solution for QoS. . . . . . . . 11   2.  Solution Proposal. . . . . . . . . . . . . . . . . . . . . . 12     2.1.  Call admission/preemption procedure. . . . . . . . . . . 13     2.2.  Voice handling characteristics. . . . . . . . . . . . . . 16 -    2.3.  Bandwidth admission procedure. . . . . . . . . . . . . . 18 +    2.3.  Bandwidth admission procedure. . . . . . . . . . . . . . 17       2.3.1.  RSVP procedure: explicit call admission - RSVP Admission using Policy for both unicast and multicast sessions. . . . . . . . . . . . . . . . . . 18       2.3.2.  RSVP Scaling Issues. . . . . . . . . . . . . . . . . 20       2.3.3.  RSVP Operation in backbones and VPNs. . . . . . . . . 20       2.3.4.  Interaction with the Differentiated Services Architecture. . . . . . . . . . . . . . . . . . . . . 21 -      2.3.5.  Admission policy. . . . . . . . . . . . . . . . . . . 22 -        2.3.5.1.  Admission for variable rate codecs. . . . . . . . 22 -        2.3.5.2.  Interaction with complex admission policies, -                  AAA, and preemption of bandwidth. . . . . . . . . 23 +      2.3.5.  Admission policy. . . . . . . . . . . . . . . . . . . 21     2.4.  Authentication and authorization of calls placed. . . . . 24     2.5.  Defined User Interface. . . . . . . . . . . . . . . . . . 24   3.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 25   4.  Security Considerations. . . . . . . . . . . . . . . . . . . 26   5.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 27   6.  References. . . . . . . . . . . . . . . . . . . . . . . . . . 28     6.1.  Normative References. . . . . . . . . . . . . . . . . . . 28     6.2.  Integrated Services Architecture References. . . . . . . 28     6.3.  Differentiated Services Architecture References. . . . . 29     6.4.  Session Initiation Protocol and related References. . . . 30     6.5.  Informative References. . . . . . . . . . . . . . . . . . 30   Appendix A.  2-Call Preemption Example using RSVP. . . . . . . . 32 -  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 44 -  Intellectual Property and Copyright Statements. . . . . . . . . . 45 - 1. Overview of the Internet Emergency Preference Service problem and proposed solutions [RFC3689] and [RFC3690] detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preference Service (IEPS) would be a part. Some of these types of   services require call preemption; others call for call queuing or    other mechanisms. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of   crisis. @@ -167,21 +146,25 @@ 1.1.1. Multi-Level Preemption and Precedence The Assured Service is designed as an IP implementation of an   existing ITU-T/NATO/DoD telephone system architecture known as Multi- Level Preemption and Precedence [ITU.MLPP.1990] [ANSI.MLPP.Spec] [ANSI.MLPP.Supplement], or MLPP. MLPP is an architecture for a   prioritized call handling service such that in times of emergency in    the relevant NATO and DoD commands, the relative importance of    various kinds of communications is strictly defined, allowing higher precedence communication at the expense of lower precedence -  communications. These precedences, in descending order, are: +  communications. This document describes NATO and U.S. Department of +  Defense uses of MLPP, but the architecture and standard are +  applicable outside of these organizations. + +  These precedences, in descending order, are: Flash Override Override: used by the Commander in Chief, Secretary of Defense, and Joint Chiefs of Staff, Commanders of combatant commands when declaring the existence of a state of war. Commanders of combatant commands when declaring Defense Condition One or Defense Emergency or Air Defense Emergency and other national authorities that the President may authorize in      conjunction with Worldwide Secure Voice Conferencing System conferences. Flash Override Override cannot be preempted. This precedence level is not enabled on all DoD networks. @@ -260,20 +243,23 @@ 1.1.2. Government Emergency Telecommunications Service A US service similar to MLPP and using MLPP signaling technology, but built for use in civilian networks, is the Government Emergency Telecommunications Service (GETS). This differs from MLPP in two ways: it does not use preemption, but rather reserves bandwidth or   queues calls to obtain a high probability of call completion, and it    has only two levels of service: "Routine" and "Priority". +  GETS is described here as another example. Similar architectures are +  applied by other governments and organizations. + 1.2. Definition of Call Admission Traditionally, in the PSTN, Call Admission Control (CAC) has had the responsibility of implementing bandwidth available thresholds (e.g.   to limit resources consumed by some traffic) and determining whether a caller has permission (e.g., is an identified subscriber, with   identify attested to by appropriate credentials) to use an available circuit. IEPS, or any emergency telephone service, has additional options that it may employ to improve the probability of call completion: @@ -451,30 +436,32 @@   a server, the simplest and cheapest solution is to buy the next faster interface - substitute 100 MBPS for 10 MBPS Ethernet, 1 Gigabit for 100 MBPS, or for that matter upgrade to a ten gigabit Ethernet. Similarly, in optical networking environments, the simplest and cheapest solution is often to increase the data rate of   the optical path either by selecting a faster optical carrier or    deploying an additional lambda. In places where the bandwidth can be   over-provisioned to a point where loss or queuing delay are negligible, 10:1 over-provisioning is often the cheapest and surest solution, and by the way offers a growth path for future -  requirements. However, there are places in communication networks -  where bandwidth is not free and is therefore not effectively -  infinite. It is in these places, and only these places, where the -  question of resource management is relevant. - -  The places where bandwidth constriction takes place is typically -  where one pays a significant amount for bandwidth, such as in access -  paths, or where available technology limits the options. In military -  networks, Type 1 encryption often presents such a barrier, as do -   satellite links and various kinds of radio systems. +  requirements. However, there are many places in communication +  networks where the provision of effectively infinite bandwidth is not +  feasible, including many access networks, satellite communications, +  fixed wireless, airborn and marine communications, island +  connections, and connections to regions in which fiber optic +  connections are not cost-effective. It is in these places where the +  question of resource management is relevant. Specifically, we do not +  recommend the deployment of significant QoS procedures on links in +   excess of 100 MBPS apart from the provision of aggregated services +  that provide specific protection to the stability of the network or +   the continuity of real-time traffic as a class, as the mathematics of +   such circuits do not support this as a requirement. In short, the fact that we are discussing this class of policy control says that such constrictions in the network exist and must be    dealt with. However much we might like to, in those places we are not solving the problem with bandwidth. 2. Solution Proposal A typical voice or video network, including a backbone domain, is   shown in Figure 1. @@ -533,28 +520,27 @@   o  Does the call actually work, or do other impairments (loss, delay) make the call unusable? 2.1. Call admission/preemption procedure Administrative Call Admission is the objective of SIP and H.323. It   asks fundamental questions like "what IP address is the callee at?" and "Did you pay your bill?". For specialized policy like call preemption, two capabilities are -  necessary from an administrative perspective: -  [I-D.ietf-sip-resource-priority] provides a way to communicate -  policy-related information regarding the precedence of the call; and -  [I-D.ietf-sipping-reason-header-for-preemption] provides a reason -  code when a call fails or is refused, indicating the cause of the -  event. If it is a failure, it may make sense to redial the call. If -  it is a policy-driven preemption, even if the call is redialed it may -  not be possible to place the call. Requirements for this service are +  necessary from an administrative perspective: [RFC4412] provides a +   way to communicate policy-related information regarding the +  precedence of the call; and [RFC4411] provides a reason code when a +   call fails or is refused, indicating the cause of the event. If it +  is a failure, it may make sense to redial the call. If it is a +  policy-driven preemption, even if the call is redialed it may not be +   possible to place the call. Requirements for this service are further discussed in [RFC3689]. The Communications Resource Priority Header (or RP Header) serves the call set-up process with the precedence level chosen by the initiator of the call. The syntax is in the form: Resource Priority : namespace.priority level The "namespace" part of the syntax ensures the domain of significance to the originator of the call, and this travels end-to-end to the @@ -582,44 +568,42 @@        dsn.flash dsn.immediate dsn.priority dsn.routine The US Defense Red Switched Network (DRSN), as another example that -  is to be IANA registered in [I-D.ietf-sip-resource-priority], has 6 -  levels of precedence. The DRSN simply adds one higher precedence -  level than flash-override: +  is to be IANA registered in [RFC4412], has 6 levels of precedence. +  The DRSN simply adds one higher precedence level than flash-override: drsn.flash-override-override to be used by the President and a select few others. Note that the namespace changed for this level. The lower 5 levels within the DRSN would also have this as their namespace for all DRSN originated call set-up requests. The Resource-Priority Header (RPH) informs both the use of DSCPs by   the callee (who needs to use the same DSCP as the caller to obtain    the same data path service) and to facilitate policy-based preemption of calls in progress when appropriate. Once a call is established in an IEPS domain, the Reason Header for -  Preemption, described in -   [I-D.ietf-sipping-reason-header-for-preemption], ensures that all SIP -  nodes are synchronized to a preemption event occurring either at the -  endpoint or in a router that experiences congestion. In SIP, the -  normal indication for the end of a session is for one end system to -   send a BYE Method request as specified in [RFC3261]. This, too, is -  the proper means for signaling a termination of a call due to a +   Preemption, described in [RFC4411], ensures that all SIP nodes are +  synchronized to a preemption event occurring either at the endpoint +  or in a router that experiences congestion. In SIP, the normal +  indication for the end of a session is for one end system to send a +   BYE Method request as specified in [RFC3261]. This, too, is the +  proper means for signaling a termination of a call due to a    preemption event, as it essentially performs a normal termination with additional information informing the peer of the reason for the abrupt end - it indicates that a preemption occurred. This will be   used to inform all relevant SIP entities, and whether this was a    endpoint generated preemption event, or that the preemption event occurred within a router along the communications path (described in   Section 2.3.1 ). Figure 2 is a simple example of a SIP call set-up that includes the layer 7 precedence of a call between Alice and Bob. After Alice @@ -681,22 +664,22 @@   The Quality of Service architecture used in the data path is that of    [RFC2475]. Differentiated Services uses a flag in the IP header called the DSCP [RFC2474] to identify a data stream, and then applies a procedure called a Per Hop Behavior, or PHB, to it. This is   largely as described in the [RFC2998]. In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] describes the fundamental needs of voice and video traffic. This PHB entails ensuring that sufficient bandwidth is dedicated to real-time traffic to ensure minimal variation in delay and a minimal loss rate, -  as codecs are hampered by excessive loss [G711.1] [G711.2] [G711.3] -  .In parts of the network where bandwidth is heavily over-provisioned, +  as codecs are hampered by excessive loss [G711.1][G711.2][G711.3]. +  In parts of the network where bandwidth is heavily over-provisioned, there may be no remaining concern. In places in the network where bandwidth is more constrained, this may require the use of a priority queue. If a priority queue is used, the potential for abuse exists, meaning that it is also necessary to police traffic placed into the queue to detect and manage abuse. A fundamental question is "where   does this policing need to take place?". The obvious places would be   the first hop routers and any place where converging data streams might congest a link. Some proposals mark traffic with various code points appropriate to @@ -805,22 +788,22 @@ | |      |  |process|  _____ |     ||Routing|  |process|  _____ | | |_._____| |       -->Policy|     ||       <-->       -->Policy|| |  |        |__.__._| |Cntrl||     ||process|  |__.__._| |Cntrl|| |  |data       |  |   |_____||     ||__.____|     |  |   |_____|| |===|===========|==|==========|    |===|==========|==|==========|   |   |   |  |    _____ |     |   |  |  |    _____ |   |   |  |        |  >Admis||     |   |  |       |  >Admis|| | _V__V_    ___V____  |Cntrl||     |  _V__V_    __V_____ |Cntrl|| | |     |  |        | |_____||     | |      |  |        ||_____||   | |Class-|  | Packet |        |     | |Class-|  | Packet |       | - | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> - | |______|  |________|        |data | |______|  |________|       |data +  | | ifier|==>Schedulr|================> ifier|==>Schedulr|=========> +  | |______|  |________|        |data | |______|  |________|      data |                            |     |                            |   |_____________________________|     |____________________________|                     Figure 3: RSVP in Hosts and Routers Figure 3 shows the internal process of RSVP in both hosts (end   systems) and routers, as shown in [RFC2209]. RSVP uses the phrase "traffic control" to describe the mechanisms of   how a data flow receives quality of service. There are 3 different @@ -1181,114 +1164,89 @@   [RFC3247]  Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.              Ramakrishnan, "Supplemental Information for the New               Definition of the EF PHB (Expedited Forwarding Per-Hop               Behavior)", RFC 3247, March 2002. 6.4. Session Initiation Protocol and related References -  [I-D.ietf-sip-resource-priority] -             Schulzrinne, H. and J. Polk, "Communications Resource -              Priority for the Session Initiation Protocol (SIP)", -             draft-ietf-sip-resource-priority-10 (work in progress), -             July 2005. - -  [I-D.ietf-sipping-reason-header-for-preemption] -             Polk, J., "Extending the Session Initiation Protocol -              Reason Header for Preemption  Events", -             draft-ietf-sipping-reason-header-for-preemption-04 (work -              in progress), September 2005. -   [RFC2327]  Handley, M. and V. Jacobson, "SDP: Session Description               Protocol", RFC 2327, April 1998. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E.              Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. -  [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason -              Header Field for the Session Initiation Protocol (SIP)", -             RFC 3326, December 2002. +  [RFC4411]  Polk, J., "Extending the Session Initiation Protocol (SIP) +              Reason Header for Preemption Events", RFC 4411, +             February 2006. + +  [RFC4412]  Schulzrinne, H. and J. Polk, "Communications Resource +              Priority for the Session Initiation Protocol (SIP)", +             RFC 4412, February 2006. 6.5. Informative References -  [ANSI.MLPP.Spec] -             American National Standards Institute, "Telecommunications -              - Integrated Services Digital Network (ISDN) - Multi-Level -              Precedence and Preemption (MLPP) Service Capability", -             ANSI T1.619-1992 (R1999), 1992. +  [ANSI.MLPP.Spec]        American National Standards Institute, +                          "Telecommunications - Integrated Services +                           Digital Network (ISDN) - Multi-Level +                           Precedence and Preemption (MLPP) Service +                           Capability", ANSI T1.619-1992 (R1999), 1992. -  [ANSI.MLPP.Supplement] -             American National Standards Institute, "MLPP Service -              Domain Cause Value Changes", ANSI ANSI T1.619a-1994 -             (R1999), 1990. +  [ANSI.MLPP.Supplement]  American National Standards Institute, "MLPP +                           Service Domain Cause Value Changes", +                          ANSI ANSI T1.619a-1994 (R1999), 1990. -  [G711.1]   Viola Networks, "Netally VoIP Evaluator", January 2003, . -  [G711.2]   IEPSI Tiphon, "IEPSI Tiphon Temporary Document 64", -             July 1999, . +  [G711.2]                IEPSI Tiphon, "IEPSI Tiphon Temporary +                           Document 64", July 1999, . [G711.3]  Nortel Networks, "Packet Loss and Packet Loss -              Concealment", 2000, . - -  [G711.4]   Clark, A., "Modeling the Effects of Burt Packet Loss and -              recency on Subjective Voice Quality", 2000, . - -  [G711.5]   Cisco Systems, "Understanding Codecs: Complexity, Hardware -              Support, MOS, and Negotiation", 2003, . - -  [ILBC]     Chen, M. and M. Murthi, "On The Performance Of ILBC Over -              Networks With Bursty Packet Loss", July 2003. - -  [ITU.ETS.E106] -             International Telecommunications Union, "International -              Emergency Preference Scheme for disaster relief operations -              (IEPS)", ITU-T Recommendation E.106, October 2003. +                          Concealment", 2000, . -   [ITU.MLPP.1990] -              International Telecommunications Union, "Multilevel -             Precedence and Preemption Service (MLPP)", ITU- -              T Recommendation I.255.3, 1990. +   [ITU.ETS.E106]          International Telecommunications Union, +                           "International Emergency Preference Scheme +                          for disaster relief operations (IEPS)", ITU- +                           T Recommendation E.106, October 2003. -   [Parekh1]  Parekh, A. and R. Gallager, "A Generalized Processor -             Sharing Approach to Flow Control in Integrated Services -             Networks: The Multiple Node Case", INFOCOM 1993: 521-530, -              1993. +   [ITU.MLPP.1990]         International Telecommunications Union, +                           "Multilevel Precedence and Preemption Service +                          (MLPP)", ITU-T Recommendation I.255.3, 1990. -   [Parekh2]  Parekh, A. and R. Gallager, "A Generalized Processor -             Sharing Approach to Flow Control in Integrated Services -             Networks: The Single Node Case", INFOCOM 1992: 915-924, -              1992. +   [Parekh1]               Parekh, A. and R. Gallager, "A Generalized +                          Processor Sharing Approach to Flow Control in +                           Integrated Services Networks: The Multiple +                          Node Case", INFOCOM 1993: 521-530, 1993. -   [RFC3951]  Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, -              W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", -              RFC 3951, December 2004. +   [Parekh2]               Parekh, A. and R. Gallager, "A Generalized +                          Processor Sharing Approach to Flow Control in +                           Integrated Services Networks: The Single Node +                          Case", INFOCOM 1992: 915-924, 1992. Appendix A.  2-Call Preemption Example using RSVP    This appendix will present a more complete view of the interaction    between SIP, SDP and RSVP.  The bulk of the material is referenced -   from [RFC2327], [RFC3312], -   [I-D.ietf-sipping-reason-header-for-preemption], -   [I-D.ietf-sip-resource-priority].  There will be some discussion on -   basic RSVP operations regarding reservation paths, this will be -   mostly from [RFC2205]. +   from [RFC2327], [RFC3312], [RFC4411], and [RFC4412].  There will be +   some discussion on basic RSVP operations regarding reservation paths, +   this will be mostly from [RFC2205].    SIP signaling occurs at the Application Layer, riding on a UDP/IP or    TCP/IP (including TLS/TCP/IP) transport that is bound by routing    protocols such as BGP and OSPF to determine the route the packets traverse through a network between source and destination devices. RSVP is riding on top of IP as well, which means RSVP is at the mercy of the IP routing protocols to determine a path through the network between endpoints. RSVP is not a routing protocol. In this appendix there will be a escalation of building blocks getting to how the many layers are involved in SIP with QoS Preconditions requiring @@ -1774,21 +1731,21 @@   equates to a precedence value of "immediate", which is a higher priority. Thus, R2 will preempt the reservation from Alice to Bob, and allow the reservation request from Dave to Carol. The proper RSVP error is the ResvErr that indicates preemption. This message travels downstream towards the originator of the RESV message (Bob). This clears the reservation in all routers downstream of R2 (meaning   R3 and R4). Once Bob receives the ResvErr message indicating preemption has occurred on this reservation, Bob's UA transmits a SIP preemption indication back towards Alice's UA. This accomplishes two things: first it informs all SIP Servers that were in the session -  set-up path that wanted to remain "dialog stateful" per [RFC3261]], +  set-up path that wanted to remain "dialog stateful" per [RFC3261], and informs Alice's UA that this was a purposeful termination, and to   play a preemption tone. The proper indication in SIP of this termination due to preemption is a BYE Method message that includes a   Reason Header indicating why this occurred (in this case, "Reserved    Resources Preempted".  Here is that message from Bob to Alice that    terminates the call in SIP.       BYE sip:alice@usmc.example.mil SIP/2.0       Via: SIP/2.0/TCP swp34.usmc.example.mil         ;branch=z9hG4bK776asegma @@ -1828,30 +1785,30 @@ Authors' Addresses    Fred Baker    Cisco Systems    1121 Via Del Rey    Santa Barbara, California  93117    USA    Phone: +1-408-526-4257    Fax:   +1-413-473-2403 -   Email: fred@cisco.com +   EMail: fred@cisco.com    James Polk    Cisco Systems    2200 East President George Bush Turnpike    Richardson, Texas  75082    USA    Phone: +1-817-271-3552 -   Email: jmpolk@cisco.com +   EMail: jmpolk@cisco.com Full Copyright Statement    Copyright (C) The Internet Society (2006).    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 @@ -1879,14 +1836,16 @@ 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. -Acknowledgment +Acknowledgements -  Funding for the RFC Editor function is currently provided by the -  Internet Society. +  Funding for the RFC Editor function is provided by the IETF +  Administrative Support Activity (IASA). This document was produced +  using xml2rfc v1.31pre5 (of http://xml.resource.org/) from a source +  in RFC-2629 XM