rfc2905.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,607 行 · 第 1/5 页

          :  *          +---:---------+        +---*--:------+
          :  *          |   :         |        |   *  :      |
          :  *          | +-:-------+ |        | +-O--:----+ |
          :  *          | |{C}      | |        | |   {C}   | |
      +---:--O+         | |Bandwidth| |        | |Bandwidth| |
      |  {C}  O***********O Broker  O************O Broker  | |
      |Service|         | +----O----+ |        | +----O----+ |
      |User   |=========|      *      |========|      *      |
      |       |         | +----0----+ |        | +----O----+ |
      |       |         | |Network  | |        | |Network  | |
      +-------+         | |Routing  | |        | |Routing  | |
                        | |Devices  | |        | |Devices  | |
                        | +---------+ |        | +---------+ |
                        | Autonomous  |        | Autonomous  |
                        | Service     |        | Service     |
                        | Domain A    |        | Domain B    |
                        +-------------+        +-------------+

      ==== contractual relationship
      O**O trust relationship
      {C}. certification process

     Fig. 9 -- Two-Tier Multi-Domain Trust Relationships, alt 3

4.5.  Communication Models and Trust Relationships

   When describing the Bandwidth Broker communication model, it is
   important to recognize that trust relationships between components
   must ensure secure and authenticated communication between the
   involved components.  As the Internet 2 Qbone Bandwidth Broker work
   does not recommend any particular trust relationship model, we make
   the same assumptions as [13].  In theory, the trust model and
   communication model can be independent, however communication
   efficiency will determine the most logical approach.









Vollbrecht, et al.           Informational                     [Page 18]

RFC 2905         AAA Authorization Application Examples      August 2000


4.6.  Bandwidth Broker Communication Models

4.6.1.  Concepts

   The current Internet 2 Qbone Bandwidth Broker discussion describes a
   two-tier model, where a Bandwidth Broker accepts Resource Allocation
   Requests (RAR's) from users belonging to its domain or RAR's
   generated by upstream Bandwidth Brokers from adjacent domains.  Each
   Bandwidth Broker will manage one service domain and subsequently
   provide authorization based on a policy that decides whether a
   request can be honored.

4.6.1.1.  Intra-Domain Authorization

   Admission Authorization or Connection Admission Control (CAC) for
   intra-domain communication is performed using whatever method is
   appropriate for determining availability of resources within the
   domain. Generally a Bandwidth Broker configures its service domain to
   certain levels of service.  RAR's are subsequently accommodated using
   a policy-based decision.

4.6.1.2.  Inter-Domain Authorization

   Service Level Specifications (SLS's) provide the basis for handling
   inter-domain bandwidth authorization requests.  A Bandwidth Broker
   monitors both the state of its network components and the state of
   its connections to neighboring networks.  SLS's are translations of
   SLA's established between Autonomous Service Domains.  Each Bandwidth
   Broker will initialize itself so it is aware of existing SLS's.
   SLS's are established in a unidirectional sense.  Two SLS's must
   govern a bi-directional connection.  SLS's are established on the
   level of aggregate data-flows and the resources (bandwidth)
   provisioned for these flows.

   A Bandwidth Broker may honor an inter-domain RAR by applying policy
   decisions determining that a particular RAR does fit into a pre-
   established SLS.  If successful, the Bandwidth Broker will authorize
   the usage of the bandwidth.  If unsuccessful, the Bandwidth Broker
   may deny the request or approve the request after it has re-
   negotiated the SLS with its downstream Bandwidth Broker.

   A separate Policy Manager may be involved in the CAC decision.  The
   Internet 2 Qbone Bandwidth Broker discussion recognizes an ideal
   environment where Bandwidth Brokers and Policy Managers work together
   to provide CAC using integrated policy services [13].






Vollbrecht, et al.           Informational                     [Page 19]

RFC 2905         AAA Authorization Application Examples      August 2000


4.6.2.  Bandwidth Broker Work Phases

   The Internet 2 Qbone Bandwidth Broker discussion proposes development
   of the Bandwidth Broker model in several phases:

   -  Phase 0: Local Admission.  RAR's are only handled within a local
      domain. SLS's are pre-established using manual methods (fax, e-
      mail).

   -  Phase 1: Informed Admission.  RAR's spanning multiple domains are
      authorized based on information obtained from one or more
      Bandwidth Brokers along the path.

   -  Phase 2: Dynamic SLS admission.  Bandwidth Brokers can dynamically
      set up new SLS's.

   Although the local admission case is addressed, the current Internet
   2 Qbone Bandwidth Broker work is currently concerned with solving
   multi-domain problems in order to allow individual Bandwidth Brokers
   to inter-operate as identified in phase 0 or 1.

4.6.3.  Inter-Domain Signaling

4.6.3.1.  Phase 0

   In phase 0 implementations, no electronic signaling between Bandwidth
   Brokers is performed and SLS negotiation will be performed manually
   (phone, email etc) by network operators.  An RAR is only handled
   within the domain and may originate from a User or ingress router.

4.6.3.2.  Phase 1

   Here a CAC decision is made on information obtained from downstream
   Bandwidth Brokers.  This information could come from the next hop
   Bandwidth Broker or all Bandwidth Brokers downstream to the
   destination.

   Two fundamental signaling approaches between Bandwidth Brokers have
   been identified for the Informed Admission case.  These are
   illustrated in figure 10.











Vollbrecht, et al.           Informational                     [Page 20]

RFC 2905         AAA Authorization Application Examples      August 2000


   +-------+         +-------+         +-------+         +-------+
   |       |         |       |         |       |         |       |
   |       |RAR      |       |    1    |       |   2     |       |
   | User  |-------->|       |-------->|       |-------->|       |
   |       |     RAA | BB1   |    4    |  BB2  |   3     |  BB3  |
   |       |<--------|       |<--------|       |<--------|       |
   |       |         |       |         |       |         |       |
   |       |         |       |         |       |         |       |
   +-------+         +-------+         +-------+         +-------+

   A)End-to-end signaling

   +-------+         +-------+         +-------+         +-------+
   |       |         |       |         |       |         |       |
   |       |RAR      |       |    1    |       |   3     |       |
   | User  |-------->|       |-------->|       |-------->|       |
   |       |     RAA | BB1   |    2    |  BB2  |   4     |  BB3  |
   |       |<--------|       |<--------|       |<--------|       |
   |       |    7    |       |    6    |       |   5     |       |
   |       |<--------|       |<--------|       |<--------|       |
   +-------+         +-------+         +-------+         +-------+

   B) Immediate response signaling.

            Fig. 10 -- Fundamental Signalling Approaches

   -  End to End signaling.  An RAR from a User to BB1 is forwarded to
      BB2 (1). BB2 will forward the request to BB3 (2).  If BB3 is the
      destination of the request, BB3 will authorize the request and
      reply to BB2 (3).  BB2 will then reply to BB1 (4), and BB1 will
      send a Resource Allocation Answer (RAA) back to the User to
      complete the authorization.

   -  Immediate response signaling.  This is the case where BB1 will
      want to authorize an RAR from its domain and forwards the
      authorization request to BB2 (1).  If BB2 approves, the response
      is immediately returned to BB1 (2).  BB1 will send an RAA back to
      the User.  If the authorization was positive BB2 will forward
      subsequently a request to the next BB, BB3 (3).  BB3 authorizes
      the request and responds to BB2 (4).  If the response is negative
      (5), BB2 will cancel the authorization it previously issued to BB1
      (6) and this will result in a cancellation from BB1 to the user
      (7).  In this case the RAA authorization is valid until revoked by
      7.







Vollbrecht, et al.           Informational                     [Page 21]

RFC 2905         AAA Authorization Application Examples      August 2000


4.6.4.  Bandwidth Broker Communication Architecture

   Figure 11 shows components of the discussed Bandwidth Broker
   architecture with its interfaces.

   -  An intra-domain interface allows communication with all the
      service components within the network that the Bandwidth Broker
      controls.

   -  An inter-domain interface allows communication between Bandwidth
      Brokers of different autonomous networks.

   -  A user/application interface allows the Bandwidth Broker to be
      managed manually.  Requests can be sent from the User or a host
      application.

   -  A policy manager interface allows implementation of complex policy
      management or admission control.

   -  A routing table interface allows the Bandwidth Broker to
      understand the network topology.

   -  An NMS interface allows coordination of network provisioning and
      monitoring.



























Vollbrecht, et al.           Informational                     [Page 22]

RFC 2905         AAA Authorization Application Examples      August 2000


           adjacent BB <---------------------------> adjacent BB
                                     |
                                     V
                      +------------------------------+
                      |       | inter-domain |       |
                      |        --------------  ------|
          application |                       |  PM  |
          server  \   |                       |iface |
                   \  |-------   ---------+    ------|
                    ->| user/ | | simple  |    ------|
          user/host-->| app   | | policy  |   | NMS  |
                    ->| iface | | services|   |iface |
                   /  |-------   ---------+    ------|
          network /   |                              |
          operator    |  -------          -------    |
                      | | data  |        |routing|   |
                      | | store |        |info   |   |
                      | |       |        |       |   |
                      |  -------          -------    |
                      |                              |
                      |       ----------------       |
                      |      | intra-domain   |      |
                      +------------------------------+
                                     ^
                                     |
        edge router(s) <---------------------------> edge router(s)

              Fig. 11 -- Bandwidth Broker Architecture

4.6.5.  Two-Tier Inter-Domain Bandwidth Broker Communication Model

4.6.5.1.  Session Initialization

   Before Bandwidth Brokers can configure services between two adjacent
   domains, they have to establish and initialize a relationship.  No
   authentication is used; therefore any trust relationship is implicit.
   Part of the initialization is an exchange of topology information
   (list of adjacent Bandwidth Brokers).

4.6.5.2.  Service Setup

   The Bandwidth Broker must first be configured in regard to agreed
   bi-lateral service levels.  All resources allocated to a particular
   level of provisioned service must be reserved in each domain.

   A Service Setup Request (SSR) is generated  (on demand by the
   operator or at startup of the system) and forwarded to a downstream
   Bandwidth Broker.  The downstream Bandwidth Broker will check the