[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
 Internet Draft                                    Jim Boyle
 Expiration: January 25, 1998                         MCI
 File: draft-ietf-rsvp-pepci-00.txt                Ron Cohen
                                                      Class Data Systems
                                                   Laura Cunningham
                                                   David Durham
                                                   Arun Sastry
                                                   Raj Yavatkar

          Protocol for Exchange of PoliCy Information (PEPCI)

                             July 25, 1997

Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Boyle et. al.                Expires January 25, 1998           [Page 1]

Internet Draft                   PEPCI                     July 25, 1997


   This document describes a simple client/server model for supporting
   policy for RSVP, and is designed to be extensible so that other kinds
   of client types may be supported in the future. The model does not
   make any assumptions about the algorithm of the policy server, but is
   based on the server returning a single priority value in response to
   a policy request.  The objective is to use this very basic model to
   begin policy experimentation.

1. Introduction

   This document describes Protocol for Exchange of PoliCy Information
   (PEPCI) which can be used to exchange policy information between a
   policy server and its clients.  The policy clients are expected to be
   RSVP routers, that must exercise policy-based admission control over
   RSVP usage.  We assume that at least one policy server exists in each
   routing domain. The basic model of interaction between a policy
   server and its clients is compatible with the RSVP extensions for
   policy control [EXT].

   A chief objective of our proposal is to begin with a simple design
   for easy/quick deployment, testing, and experimentation.  The main
   characteristics of the proposed protocol include:

      1. The protocol uses TCP as the transport protocol for reliable
      exchange of messages between policy clients and a server.
      Therefore, no additional mechanisms are necessary for reliable
      communication between a server and its clients.

      2. The protocol is designed to leverage off existing RSVP
      implementations and makes extensive use of RSVP-like self-
      identifying objects.

      3. Even though the protocol is mainly intended for administration
      and enforcement of policies in conjunction with RSVP, the protocol
      may be extended for administration of other policies such as
      multicast group access and network security.

      4. The protocol relies on existing protocols for message
      authentication.  Namely IPSEC [IPSEC] can be used to authenticate
      and secure the channel between the LPM and the server and RSVP MD5
      message authentication [MD5] can be used for inter-node

Boyle et. al.                Expires January 25, 1998           [Page 2]

Internet Draft                   PEPCI                     July 25, 1997

      5. Messages are exchanged asynchronously and there is no need for
      error control or specific sequencing of messages.

1.1. Basic Model

   We assume that each participating router has a Local Policy Module
   (LPM) [LPM] and may communicate with a policy server for policy
   decisions.  It is assumed that most communication with a policy
   server will be done by border routers upon entry of an RSVP message
   into a routing domain, although this protocol is not restricted to
   such a model.

   A policy client establishes a TCP connection to the policy server to
   begin communication and uses the connection to send requests to and
   receive responses from the server. Communication between client and
   server is mainly in the form of a request/response exchange, though
   the server may occasionally send an unsolicited response to the
   client to force a change to a previously approved state.

   The response from the server is in the form of Accept(Priority). The
   priority returned by the policy server is a non-negative integer
   indicating priority. Higher numbers indicate higher priority, and the
   LPM interprets 0 as an indicator to completely deny the request. A
   single policy value indicating priority enables the routers to sort
   and kill sessions without requiring server intervention. For example,
   suppose a router has already successfully admitted and installed a
   reservation with priority 5. Later, if a new reservation request
   comes in and is approved by the policy server at priority 10, but
   cannot be admitted due to local admission control at the client, the
   client can remove the previously admitted reservation (with priority
   5) to make room for the newer, higher priority reservation.

   The LPM keeps state of known RSVP messages and processes policy as
   part of admission control. In particular, the LPM keeps track of the
   priority associated with each reservation message received. When a
   new PATH or RESV message is received, the LPM sends a new request
   message to the server.  The client includes RSVP objects from the
   message in question and establishes a request identification handle
   (RIH) for future reference to this message.  It should be noted that
   this is done rather early in RSVP processing [RSVPPROC]. The server
   responds with ACCEPT/REJECT indication and may optionally include
   objects that provide for modification of the original message.  If
   the message is accepted, it is further processed by RSVP including
   RESV merging with other messages if necessary. If RESV messages are
   merged, the client may end up with several policy objects to merge.

Boyle et. al.                Expires January 25, 1998           [Page 3]

Internet Draft                   PEPCI                     July 25, 1997

   This is resolved by attaching the Policy Object of the "largest"
   downstream RESV to the forwarded RESV message. In the event of a
   "tie" (i.e. there are multiple reservations that can be considered
   the "largest" reservation), we will include the policy objects from
   all the reservations.

Boyle et. al.                Expires January 25, 1998           [Page 4]

Internet Draft                   PEPCI                     July 25, 1997

   For example, if a router receives two RESV messages for the same
   session, it will check with the policy server separately for each
   message and then keep track of the priority received as part of the
   RSB for each message. When the two RESVs are successfully merged, the
   merged RESV is forwarded with the policy object of the "larger"
   original message.  If the higher priority reservation is later torn
   down, the existing reservation would then revert to the next
   "largest" reservation.  The RSVP implementation must keep track of
   the associated priority. This could result in the lower priority
   reservation "riding" the priority of a higher reservation and then
   being torn down once the higher priority reservation is gone and
   other reservations pre-empt the lower priority one. This is
   considered acceptable as a side effect of merging benefits.

   Under this model, both the policy server and its client maintain
   state associated with a particular request. Failure of a client or
   the server is detected by the loss of a TCP connection.  Upon
   failure, a client connects to a new server and the new server syncs
   up with the client.

Boyle et. al.                Expires January 25, 1998           [Page 5]

Internet Draft                   PEPCI                     July 25, 1997

2. The Protocol

   This section describes the message formats and objects used by the
   LPM and Policy Server.

2.1 Common Header

   Each PEPCI message consists of the PEPCI header followed by a number
   of client-specific objects.

               0              1              2              3
        |Version|Flags |       Client Type           |    Op Code   |
        |                            RIH                            |
        |                      Message Length                       |

   The fields in the header are:
      Version: 4 bits
         PEPCI version number. Current version is 1.

      Flags: 4 bits
         Flag bits

      Client Type: 16 bits
         The type identification for the policy client Interpretation of
         all encapsulated objects is relative to the client type. The
         client type of 1 indicates an RSVP client using RSVP V1
         objects. In the future, further types may be defined to
         accommodate types of policies other than bandwidth and to
         accommodate new versions of RSVP.

Boyle et. al.                Expires January 25, 1998           [Page 6]

Internet Draft                   PEPCI                     July 25, 1997

      Op Code: 8 bits
         The PEPCI operations:
           1 = Request Query           (RQ)
           2 = Request Response        (RR)
           3 = Request Allowed         (RA)
           4 = Delete Request          (DRQ)
           5 = Synchronize State Req   (SSQ)
           6 = Synchronize State Resp  (SSR)
           7 = Unsolicited Response    (USR)

      RIH (Request Identification Handle): 32 bits
         Client side value to uniquely identify message/association.
         For example, an RSVP client will provide a handle to identify a
         reservation request so that subsequent operations that apply to
         the same message can be easily identified.  Similarly, if PATH
         control is desired, an RSVP client would send the RSVP objects
         associated with the PATH to the server and supply a RIH handle
         for future references to this PATH state.

      Message Length: 32 bits
         Size of message in bytes. This includes all encapsulated
         objects, but not including the standard PEPCI header.

Boyle et. al.                Expires January 25, 1998           [Page 7]

Internet Draft                   PEPCI                     July 25, 1997

2.2 Object Formats

   All the objects follow the RSVP object format; each object consists
   of one or more 32-bit words with a one-word header, with the
   following format:

               0             1              2             3
        |       Length (bytes)      |  Class-Num  | C-Type      |
        |                                                       |
        //                  (Object contents)                   //
        |                                                       |

   The Class Numbers are chosen to start with high values so as not to
   conflict with Class Number values already defined for RSVP objects.
   The choice of PEPCI specific class numbers ensures that PEPCI-
   specific objects are never forwarded beyond the policy client.

2.2.1 RSVP Objects

   RSVP Objects can be copied as is into PEPCI messages.  The first
   Request Query which initializes the RIH for the message includes a
   large portion of the RSVP message. In a PATH message, for instance,
   there is no relevant information in the Integrity object and the
   relevant information in the RSVP common header is included with the
   PEPCI context object. So, the initial PEPCI request query from the
   LPM to the server about an RSVP PATH message includes all the
   remaining RSVP objects starting with the session object. These are
   not encapsulated into PEPCI objects.  RESV RSVP messages will contain
   the Session, Flowspec, Style, and, if applicable, the Filter objects.
   The server can return a Policy Object within a Request Response which
   the LPM must substitute for the Policy Object(s) that the router
   received within that RSVP message.

Boyle et. al.                Expires January 25, 1998           [Page 8]

Internet Draft                   PEPCI                     July 25, 1997

2.2.2 Priority Object

   As stated earlier, the priority object is used to specify the
   relative priorities among different reservation requests. A priority
   of zero indicates a DENY.

   A priority value is encoded as an unsigned, 16-bit integer value.

        Class-Num = 128, C-Type = 1
                0             1              2              3
        |          Priority           |  ////    Reserved     ////  |

2.2.3 Handle Object

   The handle object is designed to carry a handle that identifies a
   particular association (such as a complete reservation request or
   parts such as a particular PATH state).

   The handle is a 32-bit number chosen by a policy client at the time
   of sending a new request to the policy server.

   Handles are optional for both the client and server, and there is no
   special negotiation needed (between the client and server) to
   determine the usage of the handle.

        Class-Num = 129, C-Type = 1

        |              Request Identification Handle                |

Boyle et. al.                Expires January 25, 1998           [Page 9]

Internet Draft                   PEPCI                     July 25, 1997

2.2.4 Reason Code Object

   A one octet, integer value used to provide additional reasons for a
   particular response or a particular delete state notification.

        Class-Num = 130, C-Type = 1

        | Reason code  | ///////        RESERVED ///////            |

2.2.5 Hold Off Timer Object

   The Hold Off Timer is used to specify the length of time for which a
   given policy is valid, or the length of time the LPM should wait
   before asking the policy server for a new policy value for a given
   RIH. This timer acts as a simple mechanism to prevent denial of
   service attacks on a policy server. It also works to ensure that
   policy information must be renewed periodically.

   Times are encoded as 32-bit integer values and are in units of
   seconds.  The time value is treated as a delta from the point at
   which the LPM receives the message containing the Hold Off Timer.

   LPM implementation of this object is mandatory for clients, but its
   use by servers is optional.

        Class-Num = 131, C-Type = 1

        |                       Hold Off Timer                      |

Boyle et. al.                Expires January 25, 1998          [Page 10]

Internet Draft                   PEPCI                     July 25, 1997

2.2.6 Interface Object

   The interface object is used to identify particular interfaces on a
   router.  It is a 32-bit integer field whose value is the same as the
   SNMP ifIndex value for that interface.

   There are two types of interfaces : incoming interfaces and outgoing
   interfaces. An incoming interface is the interface on which the RSVP
   message was received, and an outgoing interface is one on which the
   RSVP message is being forwarded.

           Class-Num = 132, C-Type = 1

           Class-Num = 133, C-Type = 1

                0             1               2               3
       |                         ifIndex                           |

2.2.7 Context Object

   The context object carries the RSVP message type (PATH, RESV, etc.)
   of the RSVP message that triggered the query.

        Class-Num = 134, C-Type = 1
                 0             1               2               3
        | RSVP MsgType |       ////    Reserved     ////            |

Boyle et. al.                Expires January 25, 1998          [Page 11]

Internet Draft                   PEPCI                     July 25, 1997

2.3 Request Query (RQ)  LPM -> Policy Server

   The client establishes a Request Identification Handle (RIH) which
   the server maintains a state for, and uses to refer to this RSVP
   message. It also sends portions of the RSVP message so Policy Servers
   of varying complexity can use any information from the message
   without requiring that the LPM make a determination of what to parse
   out and send to the server.

   Once a RIH is established with a new request, any subsequent
   modifications of the request can be made using the RQ message with a
   previously established RIH. For example, when a change in a
   reservation happens on a refresh (or some other means such as SNMP-
   based state change on a router), the router will simply supply the
   new information in a RQ message with the existing RIH associated with
   the reservation state.

   The format of the Request Query message is as follows:

              <Request Query> ::= <Common Header>
                                  <RSVP Objects>
                                  [<Additional objects>]

   The additional objects are optional and can give more information on
   the RSVP state. For example, in queries with Path context, the
   additional objects may be a list of out-interface objects which
   specify the outgoing interfaces on which this Path message is going
   to be forwarded. Similarly, we can have a Reservation query with
   multiple objects for the associated PATH states, e.g.

              <Request Query> ::= <Common Header>
                                  <RSVP RESV Objects>
                                  <associated path handle #1>
                                  <associated path handle #2>
                                  <associated path handle #3>

Boyle et. al.                Expires January 25, 1998          [Page 12]

Internet Draft                   PEPCI                     July 25, 1997

2.4. Request Response (RR)  Policy Server -> LPM

   The server responds to the RQ with a RR message that includes the
   associated RIH and the response.  The priority value included in the
   response indicates the result such as Deny (priority = 0 means
   Reject) or Accept. In addition, the response may optionally include
   policy objects (OUT_POLICY), whose structure is defined in [EXT], to
   replace the incoming policy object(s). This assumes wholesale
   replacement of a previously received policy object(s) with
   appropriate modifications.

   In order to avoid the issue of keeping track of which Request Query a
   particular response belongs to, it is important that, for a given
   RIH, there be at most one outstanding response per query.  This
   essentially means that the client should not issue more than one RQ
   (for a given RIH) before it receives a corresponding RR.

   The format of the Request Response message is as follows:

            <Request Response> ::= <Common Header>
                                   [ <Hold Off Timer> ]
                                   [ <OUT_POLICY> ]
                                   [ <Additional objects> ]

   The additional objects are optional and can give more information on
   replacement of policy objects, and can permit the extension of policy
   enforcement capabilities. For example, the additional objects may
   carry <out-interface><OUT_POLICY> pairs, indicating that when
   forwarding the message out that particular interface, the policy
   object associated with this interface should supersede the policy
   object received. This may be useful in multicast cases where
   different policy objects should be forwarded out different
   interfaces. The exact format of additional objects is left for future
   work.  A router that does not support these additional objects should
   ignore them.

Boyle et. al.                Expires January 25, 1998          [Page 13]

Internet Draft                   PEPCI                     July 25, 1997

2.5. Request Allowed (RA) LPM -> Policy Server

   This message serves as an acknowledgment to the server that a
   particular request response has been acted upon.

           <Request Allowed> ::== <Common Header>

2.6. Delete Request (DRQ)  LPM -> Policy Server

   This message indicates to the server that the PATH or RESV state has
   been deleted. This will be used by the server to initiate appropriate
   clean up actions. Reasons may include: PATH_ or RESV_TEAR, pre-
   emption, SNMP, loss of soft state.

   The format of the Delete Request message is as follows:

           <Delete Request>  ::= <Common Header>
                                 <Reason Code Object>

   Reason Code: 16 bits

                Reason Code =   0       Unknown
                                1       Priority Changed
                                2       Pre-empted
                                3       TEAR
                                4       SNMP request
                                5       Loss of Soft State

Boyle et. al.                Expires January 25, 1998          [Page 14]

Internet Draft                   PEPCI                     July 25, 1997

2.7. Synchronize State Request (SSQ)  Policy Server -> LPM;

   The server uses this message to request a list of state that has been
   approved and not yet deleted.  A case where this would be used is in
   server connection startup time.  A long or short response may be
   provided, and is indicated by a bit in the flag value.  A short
   answer provides just a list of RIH values with their current priority
   and their context and incoming interface.  A long answer additionally
   provides the original RSVP message along with the OUT_POLICY object.

      Flag:        LONG_ANSWER             0x1

   Each RSVP message is sent in a separate policy message.

   The format of the Synchronize State Query message is as follows:

                   <Synchronize State> ::= <Common Header>

   If the RIH is specified (a nonzero value), the server queries about
   the state of a particular request.  RIH=0 indicates that server
   wishes to synchronize all the state.

2.8. Synchronize State Response (SSR) LPM -> Policy Server

   The format of the Synchronize State Response message is as follows:

                   <Synchronize State> ::= <Common Header>
                           <Priority #1><Handle #1>
                           If Long:
                           <RSVP Object><OUT-POLICY>
                           endIf Long:
                           <Priority #2><Handle #2>
                           If Long:
                           <RSVP Object><OUT-POLICY>
                           endIf Long:

Boyle et. al.                Expires January 25, 1998          [Page 15]

Internet Draft                   PEPCI                     July 25, 1997

2.9 Unsolicited Response (USR)  Policy Server -> LPM

   The server can also send an unsolicited response to a client. One
   example where this can happen is when a policy change is made at the
   server, and a corresponding change needs to be effected at the client
   (e.g. change a policy for a particular reservation to DENY, so that
   reservation needs to be deleted.)

   The format for an USR is the same as that for a RR.

2.10  ResvErr and PathErr control

   Policy control over RSVP Error messages is left as an option. RSVP
   error messages carry policy objects which may add information to the
   RSVP nodes along the way.

   Policy error messages generated by the router after the server has
   denied a query request should carry the policy objects returned in
   the query response.

   Error messages received from other routers are handled much like Path
   and Resv messages. Since policy error messages do not create states,
   the only PEPCI messages used are Request Query and Request Response.
   The router should use a temporary handle that will allow it to match
   reply to response, but otherwise has no significance.

Boyle et. al.                Expires January 25, 1998          [Page 16]

Internet Draft                   PEPCI                     July 25, 1997

3. Operation

   This section lists some sample exchanges between policy servers and
   LPM clients.

3.1. Client receives a new RSVP message, gets permission from Policy
server, and, later, deletes the state when RESV is torn down.

        Client -> Server: RQ
                "RIH=4, RSVP objects incl. policy data"
        Server -> Client: RR
                "RIH=4, Priority=5, OUT-POLICY"
        Client -> Server: RA
                "RIH=4, Priority=5"
        Client -> Server: DRQ
                "RIH=4, Reason Code = TEAR"

        Client gets another RESV for the same session. We assume that
        the client first checks with the policy server and then does
        local merging, before forwarding the resulting policy objects
        within the merged RESV towards PHOP(s).

        Client -> Server: RQ
                "RIH=11, objects in new incoming RESV inc' policy data"
        Server -> Client: RR
                "RIH=11, Priority=6, OUT-POLICY"
        Client -> Server: RA
                "RIH=11, Priority=6"

3.2.  Server changes priority of an existing request.

        Server -> Client: USR
                "RIH=4, NewPriority = 10, Reason Code = 1, OUT-POLICY"
        Client -> Server: RA
                "RIH=4, Priority=10"

        or, Server decides to pre-empt or abort a request accepted
        earlier by sending an USR with priority zero

        Server -> Client: USR
                "RIH=4, NewPriority = 0, Reason Code = 1, OUT-POLICY"
        Client -> Server: DRQ
                "RIH=4, Reason Code = Preempt"

Boyle et. al.                Expires January 25, 1998          [Page 17]

Internet Draft                   PEPCI                     July 25, 1997

3.3. Example of use of handle objects

        Client receives a PATH message, first contact the server for
        PATH control

        Client -> Server: RQ
               "RIH = 100, RSVP objects in the PATH message,
                policy data"
        Server -> Client: RR
                "RIH = 100, OUT_POLICY"

   Later, the client receives a RESV for the same session and wishes to
   include the PATH state info in its request. It uses RIH=100
   (previously established handle) to associate the relevant PATH state
   with its NEW request as in:

        Client -> Server: RQ
                "RIH=7, RSVP objects, Policy data, Handle = 100"

   Server examines the information in the Query and the information
   about the Path state stored from previous query on Path and reaches a
   policy decision:

        Server -> Client: RR
                "RIH=7, priority = 1, OUT-Policy"

Boyle et. al.                Expires January 25, 1998          [Page 18]

Internet Draft                   PEPCI                     July 25, 1997

3.4. Server inquires about RIH 4.

        Server -> Client: SSQ (Long)
        Client -> Server: SSR (Long)
                "RIH=4, Priority=10, OUT-POLICY,
                RSVP Objects "

3.5 Server requests a  list of state.

        Server -> Client: SSQ(Long, RIH=0)
        Client -> Server: SSR(Long)
                     "RIH=2, Context, In-Interface,
                           Priority=1, OUT-POLICY, RSVP_MESSAGE
                      RIH=4, Context, In-Interface,
                           Priority=10, OUT-POLICY, RSVP_MESSAGE
                      RIH=5, Context, In-Interface,
                           Priority=10, OUT-POLICY, RSVP_MESSAGE
                      RIH=8, Context, In-Interface,
                           Priority=100, OUT-POLICY, RSVP_MESSAGE"

3.6 State Torn Down

        Client -> Server: DRQ
         "RIH=4, Reason=Tear"

3.7 Admission error handling

   The client receives a RESV message and determines that this
   reservation was previously admitted using handle 100. Assuming that
   the flowspec of the new reservation is different, we might have
   something like:

         Client -> Server:  RQ
                  "RIH=100 NewFlowSpec, Policy data"
         Server -> Client:  RR
                  "RIH=100, Priority=4"

   The client tries to admit the reservation. If it fails, it tries to
   preempt installed reservations with lower priority. If it is still
   unable to admit the reservation, it does not send a RA indication,
   and performs the admission error operations as defined in [RSVP],
   including sending a ResvErr frame. According to [RSVP] the client
   should still keep the old active installed reservation. The client

Boyle et. al.                Expires January 25, 1998          [Page 19]

Internet Draft                   PEPCI                     July 25, 1997

   will send a DRQ to the server only if it deletes an active
   (RESV/PATH) state. In order to keep the server in sync, the client
   will reissue a query to approve its active state:

          Client -> Server:  RQ
                   "RIH=100 ActiveFlowSpec, Policy data"
          Server -> Client:  RR
                   "RIH=100, Priority=4"
          Client -> Server:  RA
                   "RIH=100, Priority=4"

3.8 ADSPEC control

   The following example describes a possible use of PEPCI to control
   ADSPEC values. The receiver uses the ADSPEC values received in the
   PATH message to decide on what QoS parameters are sent in the RESV
   message. The server may want to update the parameter AVAILABLE-PATH
   BANDWIDTH [INSCH] in the ADSPEC. This value carries information about
   the maximum bandwidth the receiver can successfully reserve due to
   physical resources limitations and bandwidth policy limitations.

        Client -> Server:  RQ
               "RIH=12, Path objects including Adspec, out-intfc 2 "

   Server pulls the ADSPEC from the request, and updates the Available
   path bandwidth parameter.

        Server -> Client: RR
                "RIH=12, Priority=2, out-intfc=2, newAdspec "

   Client updates the values in newAdspec, if necessary, and sends it in
   the PATH message sent via interface 2.

Boyle et. al.                Expires January 25, 1998          [Page 20]

Internet Draft                   PEPCI                     July 25, 1997

4. Security

   As mentioned in Section 2, security of RSVP messages is provided by
   inter-router MD5 authentication.  This assumes a chain-of-trust model
   for inter LPM authentication.  Security between LPM and server is
   provided by IPSEC.

   To ensure an LPM is talking to the correct policy server involves two
   issues: authentication of the policy client and server using a shared
   secret, and consistent proof that the connection remains valid. The
   shared secret requires manual configuration of keys, which is a
   maintenance issue. For validation of the connection, IPSEC AH will be

5. Open issues

6. References

[RSVP]  Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification."  Internet-Draft, draft-ietf-rsvp-spec-16.txt,
June 1997.

[EXT]   Herzog, S., "RSVP Extensions for Policy Control."  Internet-
Draft, draft-ietf-rsvp-policy-ext-02.txt, April 1997

[INSCH] Shenker, S., Wroclawski, J., "General Characterization
Parameters for Integrated Service Network Elements" Internet-Draft,
draft-ietf-intserv-charac-02.txt, October 1996

[IPSEC]  Atkinson, R., "Security Architecture for the Internet
Protocol."  RFC1825, August 1995.

[MD5]   Baker, F., "RSVP Cryptographic Authentication."  Internet-Draft,
draft-ietf-rsvp-md5-03.txt, May 1997.

[LPM]   Herzog, S., "Local Policy Modules (LPM): Policy Control for
RSVP." Internet-Draft, draft-ietf-rsvp-policy-lpm-01.ps, November 1996.

[RSVPPROC]  Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP)
- Version 1 Message Processing Rules."  Internet-Draft, draft-ietf-
rsvp-procrules-00.txt, November 1996.

Boyle et. al.                Expires January 25, 1998          [Page 21]

Internet Draft                   PEPCI                     July 25, 1997

6. Author Information and Acknowledgments

   Thanks Fred!

    Jim Boyle                      Ron Cohen
    MCI                            Class Data Systems
    2100 Reston Parkway            13 Hasadna St.
    Reston, VA 20191               Ra'anana 43650 Israel
    703.715.7006                   972.9.7462020
    jboyle@mci.net                 ronc@classdata.com

    Laura Cunningham               David Durham
    MCI                            Intel
    2100 Reston Parkway            2111 NE 25th Avenue
    Reston, VA 20191               Hillsboro, OR 97124
    703.715.7085                   503.264.6232
    lcunning@mci.net               David_Durham@ccm.jf.intel.com

    Arun Sastry                    Raj Yavatkar
    Cisco Systems                  Intel
    210 W Tasman Drive             2111 NE 25th Avenue
    San Jose, CA 95134             Hillsboro, OR 97124
    408.526.7685                   503.264.9077
    asastry@cisco.com              yavatkar@ibeam.intel.com

Boyle et. al.                Expires January 25, 1998          [Page 22]