doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc3752.txt b/doc/rfc/rfc3752.txt
new file mode 100644
index 0000000..db7ddb4
--- /dev/null
+++ b/doc/rfc/rfc3752.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          A. Barbir
+Request for Comments: 3752                               Nortel Networks
+Category: Informational                                        E. Burger
+                                             Brooktrout Technology, Inc.
+                                                                 R. Chen
+                                                               AT&T Labs
+                                                              S. McHenry
+                                                  Individual Contributor
+                                                                H. Orman
+                                               Purple Streak Development
+                                                                R. Penno
+                                                         Nortel Networks
+                                                              April 2004
+
+
+                  Open Pluggable Edge Services (OPES)
+                   Use Cases and Deployment Scenarios
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This memo provides a discussion of use cases and deployment scenarios
+   for Open Pluggable Edge Services (OPES).  The work examines services
+   that could be performed to requests and/or responses.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Types of OPES services . . . . . . . . . . . . . . . . . . . .  3
+       2.1.  Services performed on requests . . . . . . . . . . . . .  3
+             2.1.1.  Services intending to modify requests  . . . . .  3
+             2.1.2.  Services *not* intending to modify requests  . .  4
+       2.2.  Services performed on responses. . . . . . . . . . . . .  4
+             2.2.1.  Services intending to modify responses . . . . .  4
+             2.2.2.  Services *not* intending to modify responses . .  5
+       2.3.  Services creating responses. . . . . . . . . . . . . . .  5
+   3.  OPES deployment scenarios  . . . . . . . . . . . . . . . . . .  5
+       3.1.  Surrogate Overlays . . . . . . . . . . . . . . . . . . .  6
+       3.2.  Delegate Overlays  . . . . . . . . . . . . . . . . . . .  7
+
+
+
+Barbir, et al.               Informational                      [Page 1]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+       3.3.  Enterprise environment . . . . . . . . . . . . . . . . .  8
+       3.4.  Callout Servers  . . . . . . . . . . . . . . . . . . . .  9
+       3.5.  Chaining of OPES data filters and callout servers  . . .  9
+             3.5.1.  Chaining along the content path. . . . . . . . .  9
+             3.5.2.  Chaining along the callout path. . . . . . . . .  9
+   4.  Failure cases and service notification . . . . . . . . . . . . 10
+   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 11
+   6.  Informative References . . . . . . . . . . . . . . . . . . . . 11
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
+   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
+
+1.  Introduction
+
+   The Open Pluggable Edge Services (OPES) [1] architecture enables
+   cooperative application services (OPES services) between a data
+   provider, a data consumer, and zero or more OPES processors.  The
+   application services under consideration analyze and possibly
+   transform application-level messages exchanged between the data
+   provider and the data consumer.  The execution of such services is
+   governed by a set of filtering rules installed on the OPES processor.
+
+   The rules enforcement can trigger the execution of service
+   applications local to the OPES processor.  Alternatively, the OPES
+   processor can distribute the responsibility of service execution by
+   communicating and collaborating with one or more remote callout [6]
+   servers.
+
+   The document presents examples of services in which Open Pluggable
+   Edge Services (OPES) would be useful.  There are different types of
+   OPES services: services that modify requests, services that modify
+   responses, and a special case of the latter, services that create
+   responses.
+
+   The work also examines various deployment scenarios of OPES services.
+   The two main deployment scenarios, as described by the OPES
+   architecture [1], are surrogate overlays and delegate overlays.
+   Surrogate overlays act on behalf of data provider applications, while
+   delegate overlays act on behalf of data consumer applications.  The
+   document also describes combined surrogate and delegate overlays, as
+   one might find within an enterprise deployment.
+
+   The document is organized as follows: Section 2 discusses the various
+   types of OPES services.  Section 3 introduces OPES deployment
+   scenarios.  Section 4 discusses failure cases and service
+   notification.  Section 5 discusses security considerations.
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 2]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+   The IAB has expressed architectural and policy concerns [2] about
+   OPES.  Other OPES documents that may be relevant are, "OPES Service
+   Authorization and Enforcement Requirements" [5].  See references [3,
+   4] for recommended background reading.
+
+2.  Types of OPES services
+
+   OPES scenarios involve services that can be performed on requests for
+   data and/or responses.  OPES services can be classified into three
+   categories: services performed on requests, services performed on
+   responses, and services creating responses.  In Figure 1, the four
+   service activation points for an OPES processor are depicted.  The
+   data dispatcher examines OPES rules, enforces policies, and invokes
+   service applications (if applicable) at each service activation
+   point.
+
+              +------------------------------------------------+
+              |         +-------------+-------------+          |
+              |         |   Service Application     |          |
+              |         +---------------------------+          |
+         Responses      |       Data Dispatcher     |     Responses
+       <============4== +---------------------------+ <=3===========
+         Requests       |           HTTP            |      Requests
+       =============1=> +---------------------------+ ==2==========>
+              |                  OPES Processor                |
+              +------------------------------------------------+
+
+                  Figure 1: Service Activation Points
+
+2.1.  Services performed on requests
+
+   An OPES service performed on HTTP requests may occur when a request
+   arrives at an OPES processor (point 1) or when it is about to leave
+   the OPES processor (point 2).
+
+   The services performed on requests can further be divided into two
+   cases: those that intend to modify requests and those that do not.
+
+2.1.1.  Services intending to modify requests
+
+   An OPES processor may modify a service request on behalf of the data
+   consumer for various reasons, such as:
+
+   o  Owner of a Web access device might need control over what kind of
+      Web content can be accessed with the device, parental control for
+      example.
+
+   o  Organization may restrict or redirect access to certain web
+
+
+
+Barbir, et al.               Informational                      [Page 3]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+      services based on various criteria such as time of the day or the
+      employee access privileges.
+
+   o  Hiding the data consumer's identity, user agent, or referrer.
+
+   o  Adding user preferences or device profile to the service request
+      to get personalized or adapted services.
+
+   o  Blocking or redirecting a service request due to a corporate
+      policy.
+
+   An OPES processor may also modify a service request on behalf of the
+   data provider in several ways, such as:
+
+   o  Redirecting the request to a different server to reduce the server
+      work load.
+
+   o  Redirecting image requests to improve access time.
+
+2.1.2.  Services *not* intending to modify requests
+
+   An OPES processor may invoke useful service applications that do not
+   modify the user requests.  Examples include:
+
+   o  Administrative functions for the data provider, such as service
+      monitoring or usage tracking for billing purposes.
+
+   o  Useful services for the data consumer, such as user profiling
+      (with the user's consent) for service adaptation later on.
+
+2.2.  Services performed on responses
+
+   An OPES service performed on HTTP responses may occur when a response
+   arrives at an OPES processor (point 3) or when it is about to leave
+   the OPES processor (point 4).   In the case of a caching proxy, the
+   former service may be an encoding operation before the content is
+   stored in the cache, while the latter may be a decoding operation
+   before the content is returned to the data consumer.
+
+   The services performed on responses can further be divided into two
+   cases: those that intend to modify responses and those that do not.
+
+2.2.1.  Services intending to modify responses
+
+   There are several reasons why responses from the data providers might
+   be modified before delivery to the data consumer:
+
+   o  Content adaptation:  the data provider may not have all the device
+
+
+
+Barbir, et al.               Informational                      [Page 4]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+      profiles and templates necessary to transcode the original content
+      into a format appropriate for mobile devices of limited screen
+      size and display capabilities.
+
+   o  Language translation:  the data provider may not have all the
+      translation capabilities needed to deliver the same content in
+      multiple languages to various areas around the world.  An OPES
+      processor may perform the language translation or it may invoke
+      different callout servers to perform different language
+      translation tasks.
+
+2.2.2.  Services *not* intending to modify responses
+
+   An OPES service may be performed on the responses without modifying
+   them.  Examples include:
+
+   o  Logging/Monitoring: Each response may be examined and recorded for
+      monitoring or debugging purposes.
+
+   o  Accounting: An OPES processor may record the usage data (time and
+      space) of each service request for billing purposes.
+
+2.3.  Services creating responses
+
+   Services creating responses may include OPES services that
+   dynamically assemble web pages based on the context of the data
+   consumer application.
+
+   Consider a content provider offering web pages that include a local
+   weather forecast based on the requestor's preferences.  The OPES
+   service could analyze received requests, identify associated user
+   preferences, select appropriate templates, insert the corresponding
+   local weather forecasts, and would then deliver the content to the
+   requestor.  Note that the OPES processor may perform the tasks with
+   or without direct access to the weather data.  For example, the
+   service could use locally cached weather data or it could simply
+   embed a URL pointing to another server that holds the latest local
+   weather forecast information.
+
+3.  OPES deployment scenarios
+
+   OPES entities can be deployed over an overlay network that supports
+   the provisioning of data services in a distributed manner.  Overlay
+   networks are an abstraction that creates a virtual network of
+   connected devices layered on an existing underlying IP networks in
+   order to perform application level services.
+
+   The use of overlay networks creates virtual networks that via OPES
+
+
+
+Barbir, et al.               Informational                      [Page 5]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+   entities enables the necessary network infrastructure to provide
+   better services for data consumer and provider applications.  At the
+   application level, the resulting overlay networks are termed OPES
+   Services Networks.
+
+   There are two parties that are interested in the services that are
+   offered by OPES entities, the delegate and the surrogate.  Delegates
+   are authorized agents that act on behalf of data consumers.
+   Surrogates are authorized agents that act on behalf of data
+   providers.
+
+   All parties that are involved in enforcing policies must communicate
+   the policies to the parties that are involved.  These parties are
+   trusted to adhere to the communicated policies.
+
+   In order to delegate fine-grained trust, the parties must convey
+   policy information by implicit contract, by a setup protocol, by a
+   dynamic negotiation protocol, or in-line with application data
+   headers.
+
+3.1.  Surrogate Overlays
+
+   A surrogate overlay is a specific type of OPES service network, which
+   is delegated the authority to provide data services on behalf of one
+   or more origin servers.  Such services include, but are not limited
+   to, dynamic assembling of web pages, watermarking, and content
+   adaptation.
+
+   The elements of surrogate overlays act on behalf of origin severs and
+   logically belong to the authoritative domain of the respective origin
+   servers.  The scenario is depicted in Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 6]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+              *********************************************
+              *                                           *
+              *    +--------+             Authoritative   *
+              *    | Origin |                    Domain   *
+              *    | Server |                             *
+              *    +--------+       +------------+        *
+              *         |           | OPES Admin |        *
+              *         |           |   Server   |        *
+              *         |           +------------+        *
+              *         |         /                       *
+              *         |       /                         *
+              * +--------------+      +-----------------+ *
+              * |     OPES     |----- | Remote Call-out | *
+              * |   Processor  |      |     Server      | *
+              * +--------------+      +-----------------+ *
+              *         |                                 *
+              *********************************************
+                        |
+                        |
+                        |
+                   +---------------------------+
+                   | Data consumer application |
+                   +---------------------------+
+
+         Figure 2: Authoritative Domains for Surrogate Overlays
+
+3.2.  Delegate Overlays
+
+   A delegate overlay is a specific type of OPES service network, which
+   is delegated the authority to provide data services on behalf of one
+   or more data consumer applications.
+
+   Delegate overlays provide services that would otherwise be performed
+   by the data consumer applications.  Such services include, but are
+   not limited to, virus scanning and content filtering.
+
+   The elements of delegate overlays logically belong to the
+   authoritative domain of the respective data consumer application.
+   The situation is illustrated in Figure 3.
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 7]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+                   +--------+
+                   | Origin |
+                   | Server |
+                   +--------+
+                        |
+                        |
+                        |
+              *********************************************
+              *         |                                 *
+              * +--------------+      +-----------------+ *
+              * |     OPES     |----- | Remote Call-out | *
+              * |    Processor |      |     Server      | *
+              * +--------------+      +-----------------+ *
+              *         |       \                         *
+              *         |         +------------+          *
+              *         |         | OPES Admin |          *
+              *         |         |   Server   |          *
+              *         |         +------------+          *
+              *    +---------------------+                *
+              *    | Data consumer Appl. | Authoritative  *
+              *    +---------------------+        Domain  *
+              *                                           *
+              *********************************************
+
+         Figure 3: Authoritative Domains for Delegate Overlays
+
+3.3.  Enterprise environment
+
+   Deployment of OPES services in an enterprise environment is unique in
+   several ways:
+
+   o  Both data providers and data consumers are in the same
+      administrative domain and trust domain.  This implies that the
+      logical OPES administrator has the authority to enforce corporate
+      policies on all data providers, data consumers, and OPES entities.
+
+   o  In the case when a callout server outside the corporate firewall
+      is invoked for services (such as language translation) that cannot
+      be performed inside the corporation, care must be taken to
+      guarantee a secure communication channel between the callout
+      server and corporate OPES entities.  The callout server must also
+      adhere to all corporate security policies for the services
+      authorized.
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 8]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+3.4.  Callout Servers
+
+   In some cases the deployment of OPES services can benefit from the
+   use of callout servers that could distribute the workload of OPES
+   processors or to contract specialized services from other OPES
+   providers.
+
+   In general, operations such as virus scanning that operate on large
+   objects are better handled through the use of a dedicated callout
+   server that is better designed to perform the memory intensive task
+   than what an OPES processor could handle.
+
+3.5.  Chaining of OPES data filters and callout servers
+
+   OPES data processors can be "chained" in two dimensions: along the
+   content path or along the callout path.  In the latter case, the
+   callout servers can themselves be organized in series for handling
+   requests.  Any content that is touched by more than one data
+   processor or more than one callout server has been handled by a
+   "chain".
+
+   NOTE: Chaining of callout servers is deferred from version 1 of the
+   Protocol.  The discussion of chaining is included here for
+   completeness.
+
+3.5.1.  Chaining along the content path
+
+   An OPES provider may have assigned OPES services to a set of
+   processors arranged in series.  All content might move through the
+   series, and if the content matches the rules for a processor, it is
+   subjected to the service.  In this way, the content can be enhanced
+   by several services.  This kind of chaining can be successful if the
+   services are relatively independent.  For example, the content might
+   be assembled by a service early in the chain and then further
+   decorated by a later service.
+
+3.5.2.  Chaining along the callout path
+
+   Alternatively, an OPES data processor might act as a content-level
+   switch in a cluster of other data processors and callout servers.
+
+   The first stage might develop a processing schedule for the content
+   and direct it to other OPES data processors and/or callout servers.
+   For example, OPES processor A might handle all services assembling
+   content, OPES processor B might handle all services involving URL
+   translation, and OPES processor C might handle all content security
+   services.  The first processor would determine that processors A and
+
+
+
+
+Barbir, et al.               Informational                      [Page 9]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+   C were needed for a particular content object, and it would direct
+   the content to those processors.  In turn, the processors might use
+   several callout servers to accomplish the task.
+
+4.  Failure cases and service notification
+
+   These are illustrative cases where information about OPES processing
+   can help endpoint users determine where and why content modifications
+   are being performed.
+
+   o  Content provider uses an OPES data processor to enhance content
+      based only on context local to the provider.  The local context
+      might be time of day, local URL, or available advertising, for
+      example.  The content provider might find OPES logging to be
+      sufficient for debugging any problems in this case.  However, the
+      content provider might also try direct probing by issuing a
+      request for the content and examining headers related to tracing.
+      If unexpected parameters show up in the trace headers, the content
+      provider's administrator can use these to correct the OPES rules
+      or detect the presence of an unexpected OPES processor in the
+      content path.
+
+   o  Content provider uses an OPES data processor to enhance content
+      based on context related to the requestor.  The requestor may
+      notice that his requests do not elicit the same response as
+      another requestor.  He may, for example, get an error message.  If
+      he believes there is a configuration error on the OPES data
+      processor, he will need to provide information to the
+      administrator of it.  If the information includes "OPES service
+      access control, action: blocked", for example, he can inquire
+      about the circumstances that will allow him to be added to the
+      access control list.  In another example, if he sees a picture
+      unrelated to the surrounding text, and if the tracing shows "OPES
+      service choose picture, action: insert 640x480 weather.gif", he
+      might complain that the OPES service does not properly recognize
+      his geographic location and inserts the wrong weather map.  In any
+      case, if the information is forwarded to the content provider, the
+      problem may be fixed.
+
+   o  End user has OPES processor available as part of his network
+      access environment.  The end user may have selected "translate
+      English to Spanish" as an OPES service.  If he sees "OPES service
+      language translation, action: destination language not supported,
+      no action", then he may inquire of the OPES service provider about
+      what languages are supported by the package.  If the end user
+      feels that the source language is not properly represented by the
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 10]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+      provider, resulting in inability for the service to operate, he
+      (or the language service provider) can contact the content
+      provider.
+
+   o  If the content provider gets complaints from users about the
+      translation service and feels that the problem is not in the
+      content but in the service, he may recommend that the service not
+      be applied to his pages.  He can do that through content headers,
+      for example, with the notation "No OPES service #8D3298EB" or "No
+      OPES class language translation".
+
+   o  End user's ISP or enterprise uses OPES to control user access
+      based on user profiles.  The end user can see that the OPES
+      services are being applied by his ISP, but he cannot control them.
+      If he feels that the transformations bowdlerize the content he can
+      complain to the provider organization.
+
+   o  The content provider or end user relies on a content distribution
+      network and OPES is used within that network.  OPES may be
+      authorized by either the content provider, end user, or both.  The
+      content provider may suspect that his access control rules are not
+      being applied properly, for example.  He may ask for notification
+      on all accesses to his content through a log.  This request and
+      the logfile are outside the OPES architecture; there are security
+      implications for the request, the response, and the resources used
+      by the logfile.
+
+5.  Security Considerations
+
+   The document presents usage scenarios and deployment cases.  Issues
+   related to the overall security of OPES entities are given in [1].
+
+6.  Informative References
+
+   [1]  A. Barbir et al., "An Architecture for Open Pluggable Edge
+        Services (OPES)", Work in Progress, July 2002.
+
+   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
+        Considerations for Open Pluggable Edge Services", RFC 3238,
+        January 2002.
+
+   [3]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
+        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
+        Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
+        November 2001.
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 11]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+   [4]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
+        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+        HTTP/1.1", RFC 2616, June 1999.
+
+   [5]  OPES Working Group, "OPES Service Authorization and Enforcement
+        Requirements", Work in Progress, May 2002.
+
+   [6]  Beck, A., et al., "Requirements for OPES Callout Protocols",
+        Work in Progress, July 2002.
+
+7.  Acknowledgements
+
+   The authors would like to thank the participants of the OPES WG for
+   their comments on this document.
+
+8.  Authors' Addresses
+
+   Abbie Barbir
+   Nortel Networks
+   3500 Carling Avenue
+   Nepean, Ontario  K2H 8E9
+   Canada
+
+   Phone: +1 613 763 5229
+   EMail: abbieb@nortelnetworks.com
+
+
+   Eric W. Burger
+   Brooktrout Technology, Inc.
+   18 Keewaydin Dr.
+   Salem, NH  03079
+
+   EMail: e.burger@ieee.org
+
+
+   Yih-Farn Robin Chen
+   AT&T Labs - Research
+   180 Park Avenue
+   Florham Park, NJ  07932
+   US
+
+   Phone: +1 973 360 8653
+   EMail: chen@research.att.com
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 12]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+   Stephen McHenry
+   305 Vineyard Town Center, #251
+   Morgan Hill, CA  95037
+   US
+
+   Phone: +1 408 683 2700
+   EMail: stephen@mchenry.net
+
+
+   Hilarie Orman
+   Purple Streak Development
+
+   EMail: ho@alum.mit.edu
+
+
+   Reinaldo Penno
+   Nortel Networks
+   600 Technology Park Drive
+   Billerica, MA  01803
+   US
+
+   EMail: rpenno@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 13]
+
+RFC 3752                     OPES Scenarios                   April 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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 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
+
+   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.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 14]
+