Internet Draft T.M.T. Nguyen
Expires January 2003 University of Paris 6 - ENST Paris
N. Boukhatem
ENST Paris
Y. El Mghazli
N. Charton
Alcatel
Louis-Nicolas Hamer
Nortel Networks
G. Pujolle
University of Paris 6
July, 1st 2002
COPS-PR Usage for SLS negotiation (COPS-SLS)
<draft-nguyen-rap-cops-sls-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC-2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet- Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Abstract
This document describes the use of the Common Open Policy Service
(COPS) protocol for supporting Service Level Specification (SLS)
negotiation (COPS-SLS). The COPS protocol [COPS] has been defined by
the IETF Resource Allocation Protocol (RAP) WG [RAP] and will be used
in this memo to communicate SLS information between customer and
provider. COPS-SLS can be used at different interfaces such as
Nguyen, et al. Expires January 2003 [Page 1]
Internet Draft COPS-SLS July 2002
vertically between a service provider and a network provider or
horizontally between network providers in order to decide if the
network guarantees a service level for a traffic stream. This version
presents COPS-SLS as a candidate protocol for the interface between
the Resource Control Domain (RCD) and the Service Control Domain
(SCD), according to [SESSION-AUTH] vocabulary. It enables an SCD to
vertically reserve RCD resource for its customers. Once resource has
been reserved in the RCD, the media session establishment, together
with the horizontal resource reservation, follows the steps described
in the [AUTHSESSION] framework. Moreover, the respective PDPs have to
verify that all the media streams being accepted lie within the
bounds of the resource reserved in the RCD by the SCD.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].
Table of Contents
Glossary........................................................... 2
1. Introduction.................................................... 3
2. COPS-SLS Model.................................................. 5
2.1 Overall model 5
2.2 Consistency with the framework for session set-up with media
authorization.................................................. 6
3. Message Content................................................. 7
3.1. Request message (REQ) PEP -> PDP.............................. 7
3.2. Decision message (DEC) PDP -> PEP............................. 7
3.3. Report State message (RPT) PEP -> PDP......................... 8
4. COPS-SLS protocol objects and Client-Specific data format....... 9
4.1. COPS-SLS protocol objects..................................... 9
4.2. Client-Specific data format................................... 9
5. Common Operation and example.................................... 9
6. COPS-SLS PIB Module ............................................13
7. Security Considerations.........................................29
8. IANA Considerations.............................................29
9. Acknowledgements................................................29
10. References.....................................................29
11. Authors' Addresses.............................................30
12. Full Copyright Statement.......................................31
Glossary
ClientSI Client Specific Information. See [COPS]
CPERR PRC Class Provisioning Error. See [COPS-PR]
Nguyen, et al. Expires January 2003 [Page 2]
Internet Draft COPS-SLS July 2002
EPD Encoded Provisioning Instance. See [COPS-PR]
ErrorPRID Error PRID. See [COPS-PR]
GPERR Global Provisioning Error Object. See [COPS-PR]
ISP Internet Service Provider.
PDP Policy Decision Point. See [RAP]
PEP Policy Enforcement Point. See [RAP].
PIB Policy Information Base. See [COPS-PR]
PPRID Prefix PRID. See [COPS-PR]
PRID Provisioning Instance Identifier. See [COPS-PR]
RAP Resource Allocation Protocol. See [RAP]
SLS Service Level Specification. See [DS-TERM]
1. Introduction
This document describes the use of the Common Open Policy Service
(COPS) protocol [COPS] for supporting Service Level Specification
(SLS)negotiation (COPS-SLS). The COPS protocol has been defined
by the IETF Resource Allocation Protocol (RAP) WG [RAP] and will be
used in this memo to communicate the SLS information between a
customer and a network provider.
COPS-SLS can be used for horizontal as well as vertical negotiations
as illustrated in Figure 1.
+-------------------+
| Service Provider |
+-------------------+
^
| (vertical negotiation)
|
v
+------------------+ (horizontal +------------------+
| | negotiation) | |
----| Network Provider |<------------->| Network Provider |-
| | | |
+------------------+ +------------------+
Figure 1 Vertical and horizontal negotiations
In horizontal negotiation, two network providers (or two ISPs)
negotiate a service level for a traffic stream entering from one
domain to the other. Vertical negotiation takes place between a
Service Provider and a Network Provider in order for the traffic
stream to be guaranteed with a service level in the network provider
domain.
In this version, we introduce the use of COPS-SLS between the Service
Control Domain and the Resource Control Domain in the framework of
Nguyen, et al. Expires January 2003 [Page 3]
Internet Draft COPS-SLS July 2002
session set-up with media authorization [SESSION-AUTH]. The Service
Provider corresponds to the Service Control Domain and the Network
Provider corresponds to the Resource Control Domain in this
framework. COPS-SLS enables an SCD to vertically reserve RCD resource
for its customers. Once resource has been reserved in the RCD, the
media session establishment, together with the horizontal resource
reservation, follow the steps described in the [SESSION-AUTH]
framework. Moreover, the respective PDPs have to verify that all the
media streams being accepted lie within the bounds of the resource
reserved in the RCD by the SCD.
Many protocols could be envisaged between the RCD and the SCD.
This document proposes the COPS-PR protocol for the following
reasons:
- Policy-based networking provides interesting architecture concepts
for service level management.
- By designing a SLS specific PIB (Policy Information Base), no
change is needed to the COPS-PR protocol itself. This is a good
way of building on the existing technology without having to
revisit the protocol every time new information needs to be carried
by the protocol. This also provides a faster way for a deployment
without going through another cycle of standardization for the
protocol. This provides more flexibility and a standard way for the
implementations to add value by extending the standardized Policy
Control Information.
- Separation of Protocol and Policy Control Information. COPS-PR
takes the approach of defining a stable, reusable, more widely
applicable protocol. With the applicability addressed by the Policy
Control Information carried by the COPS-PR protocol.
- Provisioning functionality has generally been thought of as static,
but within the context of COPS-PR, the degree of dynamic/static is
up to the user of the technology. The events handled by COPS-PR can
be very dynamic to very static. The degree of dynamic-ness is in
itself a policy, and can be controlled with COPS-PR with
flexibility in both event detection/reporting frequency and
granularity.
- Levels of outsourcing details can be as coarse (aggregated) or fine
(per micro-flow) as necessary and can be adjusted dynamically when
needed.
COPS-SLS makes uses of both common models supported by the COPS
protocol: Outsourcing model and Configuration (a.k.a. Provisioning)
model.
Nguyen, et al. Expires January 2003 [Page 4]
Internet Draft COPS-SLS July 2002
During the negotiation phase, the customer requests a service by
triggering the PEP function which negotiate the desired SLS with the
provider. The decision sent by the PDP addresses the desired SLS sent
by the PEP. There is a direct 1:1 correlation between PEP events and
PDP decisions. Therefore, the negotiation phase follows the
Outsourcing mode as defined in RFC3084, section 1 [RFC 3084].
In order to make the negotiation configurable according to the domain
policies, a configuration phase is used in COPS-SLS. The
configuration phase follows the COPS Provisioning mode defined in
RFC3084, section 1 [RFC 3084]. The domain negotiation policies are
provisioned down to the customer. These policies indicate the service
offered by a provider, this can be the negotiable parameters, the
value constraints of these parameters, the dynamic level of the
negotiation, etc. The configuration phase is also useful to provision
pre-defined service templates that can be requested as is by the
customer in case there is a correspondence with its own needs.
[COPS-FRWK] describes in more details how COPS-PR can be utilized in
both outsourcing and configuration mode.
2. COPS-SLS model
2.1 Overall model
Policy Client (SCD/RCD) Policy Server (RCD/SCD)
+--------------+ +-----------+
| | | |
| +-----+ | REQ() | +-----+ |
| | SLS |----|--------------|->| SLS | |
| | PEP |<---|--------------|--| PDP |--|--------->
| +-----+ | DEC() | +-----+ |
| | | |
+--------------+ +-----------+
Figure 2 - COPS-SLS model
As depicted in Figure 2, the SLS Policy Client negotiates with the
SLS Policy Server using the COPS protocol. This negotiation process
can take place within an administrative domain or between
administrative domains. The SLS PEP represents the customer and the
SLS PDP represents the network provider. The customer is the entity
consuming network resources of a network provider. It may be an
enterprise, an Application Service Provider (ASP) or another network
provider.
Nguyen, et al. Expires January 2003 [Page 5]
Internet Draft COPS-SLS July 2002
When the SLS-PEP module is activated, the PEP connects to its
primary SLS-PDP. The SLS-PDP is a server who manages all SLSs of an
administrative domain. The SLS-PDP gets to its Policy Repository to
retrieve the relevant policies. The SLS policies helps the SLS-PDP to
accept or reject the requested SLS. The SLS-PDP MAY also suggest
another SLS to be applied to the PEP.
Once an SLS-PDP and an SLS-PEP agreed on a service level for a
Traffic stream, the SLS-PDP MAY interact with other entities (e.g., a
COPS-PR-DiffServ PDP) so that the network resources could be properly
provisioned. The interaction between the SLS-PDP and the other
entities is outside the scope of this document.
2.2 Consistency with the framework for session set-up with media
authorization
For vertical negotiations, i.e. negotiations between service
providers and network providers, the framework defined in [SESSION-
AUTH] should be assumed. Basically, the network provider MUST verify
with the service provider that the QoS resources requested by a
particular user are within the bounds of the authorized session.
[SESSION-AUTH] describes 4 different models: the coupled model, the
associated model with one policy server, the associated model with
two policy servers and the non-associated model.
Only the coupled & associated models apply to the original COPS-SLS
concept presented since version 00. The SCD can negotiate with the
RCD for a number of resources and distribute them to different
sessions. When the used resource arrives at a threshold, the SCD
renegotiates with the RCD to get more resources. The SCD can
dynamically negotiate resources with the RCD for each session. The
non-associated model does not require a negotiation between service
and network providers.
In the coupled & associated model with one policy server, the service
provider acts as the SLS PEP since it is consuming network resources
controlled by the SLS PDP. However, in the associated model with two
policy servers, the roles are reversed. In fact, since the service
provider does not have an a priori relationship with the network
provider, the negotiation process cannot be triggered. Instead, the
service provider will send an authorization token, providing his
identity, back to the end host. The end host relays this
authorization token to the network provider in his resource request.
The network provider can then establish communication with the
identified service provider in the authorization token. Since the
network provider requests session authorization information from the
Nguyen, et al. Expires January 2003 [Page 6]
Internet Draft COPS-SLS July 2002
service provider, the network provider acts as a PEP, while the
service provider acts as a PDP. Although the service provider is
still consuming resources from the resource provider, the latter is
the initiator (or client) of the exchange, and the former acts as the
server by providing detailed information about the authorized
session.
3. Message Content
This section presents the content of the Request, Decision and Report
messages. In this version, we only use the Named ClientSI object
defined in COPS-PR to convey information exchanged between the PEP
and the PDP both in Provisioning mode (Configuration phase) and in
Outsourcing mode (Negotiation phase). The Context Object
distinguishes the two phases: Configuration and Negotiation.
3.1. Request message (REQ) PEP -> PDP
The REQ message is sent by the SLS-PEP to the SLS-PDP with the
following format:
<Request> ::= <Common Header>
<Client Handle>
<Context>
*(<Named ClientSI>
[<Integrity>]
Note that *(<entity>) means zero or more <entity>(s). The COPS
objects IN-Int, OUT-Int and LPDPDecisions are not included in a COPS-
SLS Request.
The Context object specifies the context of the message. A 'context =
configuration request' specifies a request in the Configuration
phase. A 'Context = resource allocation request' specifies a request
in the Negotiation phase.
The Named ClientSI object is included in the REQ message to convey
negotiation's information under PIB classes' instances. In the
Configuration phase, this object is used to inform the PDP about the
PEP negotiation capabilities and all predefined SLS available in the
PEP. In the Negotiation phase, this object is used to transport the
SLS requested by the PEP.
3.2. Decision message (DEC) PDP -> PEP
The DEC message is sent by the SLS-PDP to the SLS-PEP with the
Nguyen, et al. Expires January 2003 [Page 7]
Internet Draft COPS-SLS July 2002
following format:
<Decision Message> ::= <Common Header>
<Client Handle>
*(<Decision>) | <Error>
[<Integrity>]
<Decision> ::= <Context>
<Decision Flags>
*(<Named Decision Data>)
A solicited DEC message is sent from the PDP to answer a REQ message
sent by the PEP. Unsolicited DEC messages may be sent by the PDP to
transport the updated policy information. The Client-Handle value
identifies the request to which the PDP wants to send a decision. The
Context object specifies the context of the decision ('configuration'
or 'resource-allocation').
The Named Decision Data object is included in the DEC message to
convey the PIB class instances in the decision. In the Configuration
phase, this object is used to transport the negotiation configuration
(e.g., negotiation mode, predefined SLSs, ...) which the PDP wants to
install/remove in/from the PEP. The action 'install' or 'remove' is
specified in the Decision Flags object. In the Negotiation phase,
this object is used when the PDP suggests another SLS. The Decision
Flags object will specify the action of 'install' in this case.
For the decisions which simply accept or reject the SLS indicated in
the REQ message without proposing another service level, the action
'install' or 'remove' in the Decision Flags object is sufficient. No
Named Decision Data Object is included in the DEC message to convey
the SLS proposal.
3.3. Report State message (RPT) PEP -> PDP
The RPT message is sent by the SLS-PEP to the SLS-PDP with the
following format:
<Report State> ::= <Common Header>
<Client Handle>
<Report Type>
*(<Named ClientSI>)
[<Integrity>]
A solicited RPT message MUST be sent by the PEP upon receipt of a DEC
message from the PDP. The Client-Handle object contains the same
value as the Client-Handle value in the DEC message to which the PEP
wants to make a report.
Nguyen, et al. Expires January 2003 [Page 8]
Internet Draft COPS-SLS July 2002
The Report-Type object is used to specify the action (success/fail)
taken by the PEP. The Named ClientSI objects are eventually included
in the RPT message to transport error/accounting information.
4. COPS-SLS protocol objects and Client-Specific data formats
4.1 COPS-SLS protocol objects
The COPS-SLS protocol objects follow the same object formats defined
in [COPS-PR]. More precisely, six objects (PRID object, PPRID object,
EPD object, GPERR object, CPERR object and ErrorPRID object) are
defined in section 4 of [COPS-PR].
4.2 Client-Specific data format
The Named ClientSI object used in the REQ message have the same
format as the ClientSI Request Data defined in section 5.2 of [COPS-
PR].
The Named Decision Data object used in the DEC have the same format
as the Named Decision Data defined in section 5.1 of [COPS-PR].
The Named ClientSI object used in the RPT message has the same format
as the Policy Provisioning Report Data defined in section 5.3 of
[COPS-PR]. In the case of a 'Failure' Report-Type due to the reject
of the PDP suggested SLS, the PEP MUST send a report indicating
'slsNonAccepted' using slsNegoRptEntry PRC.
5. Common Operation and example
To illustrate the operation of COPS-SLS, an example of COPS-SLS is
shown in Figure 3.
COPS-SLS-PEP COPS-SLS-PDP
| |
| |
|--------------------------------------------------->|(step 1)
| OPN : |
| Common Header : |
| Client-type = COPS-SLS (tbd) |
| PEPID : |
| PEPID = PEP_1 |
| |
|<---------------------------------------------------|(step 2)
| CAT : |
| Common Header : |
| Client-type = COPS-SLS |
Nguyen, et al. Expires January 2003 [Page 9]
Internet Draft COPS-SLS July 2002
| KA Timer : |
| KATimer = 50 |
| |
|--------------------------------------------------->|(step 3)
| REQ : |
| Common Header : |
| Client-type = COPS-SLS |
| Client-Handle : |
| Handle = config_req_A |
| Context : |
| R-Type = 0x08 (Configuration request) |
| Named ClientSI : |
| frwkPrcCapsTable |
| slsNegoCapsTable |
| slsSlsTable |
| |
|<---------------------------------------------------|(step 4)
| DEC : |
| Common Header : |
| Flags = 0x1 (solicited message) |
| Client-type = COPS-SLS |
| Client-Handle : |
| Handle = config_req_A |
| Context : |
| R-Type = 0x08 (configuration) |
| Decision : |
| Decision Flag : |
| Command Code = Install |
| Named Decision Data : |
| slsNegoTable |
| (slsNegoMode = predefined SLSs |
| slsNegoMaxInt = 120) |
| slsSlsTable |
| |
|--------------------------------------------------->|(step 5)
| RPT : |
| Common Header: |
| Flags = 0x1 (solicited message) |
| Client-Type = COPS-SLS |
| Client-Handle : |
| Handle = config_req_A |
| Report-Type : |
| Report-type = Success |
| |
|--------------------------------------------------->|(step 6)
| REQ : |
| Common Header : |
| Flags = 0 |
Nguyen, et al. Expires January 2003 [Page 10]
Internet Draft COPS-SLS July 2002
| Client-Type = COPS-SLS |
| Client-Handle : |
| Handle = res_req_B |
| Context : |
| R-Type = 0x02 (Resource-Allocation request) |
| Named ClientSI : |
| slsSlsTable |
| |
|<---------------------------------------------------|(step 7)
| DEC : |
| Common Header : |
| Flags = 0x01 (solicited message) |
| Client-Type = COPS-SLS |
| Client-Handle : |
| Handle = res_req_B |
| Context : |
| R-Type = 0x02 (Resource-Allocation) |
| Decision Flags: |
| Commande Code = install |
| |
|--------------------------------------------------->|(step 8)
| RPT : |
| Common Header : |
| Flags = 0x01 (solicited massage) |
| Client-Type = COPS-SLS |
| Client-Handle : |
| Handle = res_req_B |
| Report-Type : |
| Report-Type = Success |
Figure 3 - Example of COPS-SLS operation
The next section describes the Common Operation on the COPS-SLS
connection between the PEP and the PDP.
When the SLS-PEP module is activated, the PEP connects to its
primary SLS-PDP and sends the OPN message with a Client-Type=COPS-
SLS (Figure 3 - step 1).
If the PDP accepts this PEP, it sends to the PEP a CAT message
(Figure 3 - step 2). Otherwise, it sends a CC message.
When the COPS-SLS connection is successfully established, the PEP
sends the first REQ with a Context='configuration request'. The
Named ClientSI object is used in this request to inform the PDP about
the capabilities of the PEP (e.g, the PRCs the PEP understands, the
negotiation mode the PEP supports, ...) and all existing predefined
SLSs (Figure 3 - step 3).
Nguyen, et al. Expires January 2003 [Page 11]
Internet Draft COPS-SLS July 2002
Predefined SLS is defined in [SLS-AQU] as an SLS with predefined
values (or a range of values) for a subset of the parameters in the
generic SLS.
In predefined SLS mode, the PDP installs all predefined SLS in
the PEP. The PEP CAN only request an SLS conforming to one of
these predefined SLSs. The PEP MUST NOT request an SLS outside these
predefined SLSs.
In the non-predefined SLS mode, the PEP CAN request an SLS with any
parameter values.
Upon receipt of the REQ message, the PDP sends a solicited DEC
message with a Context='configuration' and installs the configuration
information at the PEP (Figure 3 - step 4).
After receiving the DEC message, the PEP installs the configuration
sent by the PDP and sends a RPT message to the PDP to report the
installation result (Figure 3 - step 5).
If the configuration is successfully installed, the PEP CAN now send
a REQ message with a Context='resource-allocation' to request the
desired SLS (Figure 3 - step 6).
In response to the REQ message, the PDP sends a DEC message with the
same context (i.e., resource-allocation). The PDP can accept the
requested SLS, or reject the requested SLS, or suggest another SLS.
To accept the requested SLS, the PDP sends a DEC message with a
Decision-Flags='Install' (Figure 3 - step 7). To reject the requested
SLS, the PDP sends a DEC message with a Decision-Flags='Remove'. To
suggest another SLS, the PDP sends a DEC message with a Decision-
Flags='install' and includes the suggested SLS in the Named Decision
Data object.
If the PEP receives a DEC message accepting/rejecting the requested
SLS, it installs the decision and sends a 'success' report to the PDP
(Figure 3 - step 8). If the PEP cannot install the decision,
it sends a 'failure' report to the PDP including the corresponding
Error object. If the PEP receives a DEC message suggesting another
SLS, it can accept the suggestion by sending a RPT message with a
Report-Type=Success or reject the suggested SLS by sending a RPT
message with a Report-Type=Failure and an instance of the PRC
SlsNegoRptEntry with a 'slsNegoRptFailRea = 1'.
If the PEP wants to modify some parameters of a negotiated SLS, it
sends a REQ message using the Client-Handle value identifying the SLS
and includes in the Named ClientSI object the SLS with its new
parameter values.
Nguyen, et al. Expires January 2003 [Page 12]
Internet Draft COPS-SLS July 2002
To delete a requested SLS, the PEP sends a DRQ message using the
Client-Handle value identifying the SLS to be deleted.
At any time, the PDP CAN send an unsolicited DEC message to supply
the PEP with the updated policy information or to degrade some
negotiated SLSs.
If the PEP receives a SSQ message, it reissues all requested SLSs and
finishes the synchronization period by the SSC message.
6. COPS-SLS PIB Module
This section defines the PIB used in COPS-SLS client-type. This PIB
defines the SLS parameters necessary for horizontal negotiation. The
SLS parameters are organized similarly to [SLS-TEQ] in six groups:
scope, flowId, traffic conformance, excess treatment, performance and
service schedule. More classes or attributes useful to vertical
negotiation will be added in further versions.
SLS-NEGOTIATION-PIB PIB-DEFINITIONS ::= BEGIN
IMPORTS
Unsigned32, InstanceId, MODULE-IDENTITY, OBJECT-TYPE
FROM COPS-PR-SPPI
ZerroDotZero
FROM SNMPv2-SMI [SMIv2]
ExtUTCTime
FROM SNMPv2-SMI
InetAddressType, InetAddress, InetAddressPrefixLength,
InetPortNumber
FROM INET-ADDRESS-MIB [INET-ADDR]
DscpOrAny
FROM DIFFSERV-DSCP-TC
slsPolicyPib MODULE-IDENTITY
SUBJECT-CATEGORIES { tbd - COPS-SLS Client Type }
LAST-UPDATED "200202281200Z"
ORGANIZATION "Alcatel, ENST Paris and University of Paris 6"
CONTACT-INFO "
Thi Mai Trang Nguyen
INFRES-ENST
46 Rue Barrault
75013 Paris - France
Phone: +33 1 45 81 74 61
Email: trnguyen@enst.fr
Nadia Boukhatem
INFRES-ENST
Nguyen, et al. Expires January 2003 [Page 13]
Internet Draft COPS-SLS July 2002
46 Rue Barrault
75013 Paris - France
Phone: +33 1 45 81 82 16
Email: Nadia.BouKhatem@enst.fr
Yacine El Mghazli
Alcatel R&I
Route de Nozay
F-91460 Marcoussis - FRANCE
Phone: +33 1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr
Nathalie Charton
Alcatel R&I
Route de Nozay
F-91460 Marcoussis - FRANCE
Phone: +33 1 69 63 14 85
Email: Nathalie.Charton@ms.alcatel.fr
Guy Pujolle
RP-LIP6-UPMC
8 Rue du Capitaine Scott
75015 Paris - France
Phone: +33 1 44 27 75 14
Email: Guy.Pujolle@lip6.fr"
DESCRIPTION
"The PIB module contains a set of classes
describing the policies in SLS negotiation"
::= { tbd }
slsCapabilityClasses OBJECT IDENTIFIER ::= { slsPolicyPib 1 }
slsPolicyClasses OBJECT IDENTIFIER ::= { slsPolicyPib 2 }
slsParamClasses OBJECT IDENTIFIER ::= { slsPolicyPib 3 }
slsReportClasses OBJECT IDENTIFIER ::= { slsPolicyPib 4}
slsNegoCapsTable OBJECT-TYPE
SYNTAX SEQUENCE OF SlsCapsEntry
PIB-ACCESS notify
STATUS current
DESCRIPTION
"SLS negotiation capabilities supported by the client"
::= { slsCapabilityClasses 1}
slsNegoCapsEntry OBJECT-TYPE
SYNTAX SlsNegoCapsEntry
STATUS current
DESCRIPTION
Nguyen, et al. Expires January 2003 [Page 14]
Internet Draft COPS-SLS July 2002
"An instance of this class describes the SLS negotiation
capabilities of a client"
::= { slsNegoCapsTable 1 }
PIB-INDEX { slsNegoCapsPrid }
SlsNegoCapsEntry ::= SEQUENCE {
slsNegoCapsPrid InstanceId
slsNegoCapsNegoMode BITS
slsNegoCapsNegoInt Unsigned32
slsNegoCapsMaxPredefSls Unsigned32
}
slsNegoCapsPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the class"
::= { slsNegoCapsEntry 1 }
slsNegoCapsNegoMode OBJECT-TYPE
SYNTAX BITS {
predefSls(1)
-- the ability to support predefined SLS mode
non-predefinedSls (2)
-- the ability to support non-predefined SLS mode"
}
STATUS current
DESCRIPTION
"The SLS negotiation mode supported by the PEP
(1) - predefined SLS mode
(2) - non-predefined SLS mode"
::= { slsNegoCapsEntry 2 }
slsNegoCapsNegoInt OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The desired interval before which the client could
send another REQ message to modify a
negotiated SLS"
::= { slsNegoCapsEntry 3 }
slsNegoCapsMaxPredefSls OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
Nguyen, et al. Expires January 2003 [Page 15]
Internet Draft COPS-SLS July 2002
"The maximum number of predefined SLSs that the PDP can
install at the client device. If the client does not
support the predefined SLS negotiation mode, this value
MUST be 0"
::= { slsNegoCapsEntry 4 }
slsNegoTable OBJECT-TYPE
SYNTAX SEQUENCE OF SlsNegoEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"SLS negotiation policies to be installed by the PDP"
::= { slsPolicyClasses 1 }
slsNegoEntry OBJECT-TYPE
SYNTAX SlsNegoEntry
STATUS current
DESCRIPTION
"An instance of this class describes the policies about
SLS negotiation that the PDP installs at the PEP"
PIB-INDEX { slsNegoPrid }
::= { slsNegoTable 1 }
SlsNegoEntry ::= SEQUENCE {
slsNegoPrid InstanceId
slsNegoMode BITS
slsNegoMaxInt Unsigned32
}
slsNegoPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the class"
::= { slsNegoEntry 1 }
slsNegoMode OBJECT-TYPE
SYNTAX BITS{
predefSls(1)
-- predefined SLS mode
non-predefinedSls (2)
-- non-predefined SLS mode"
}
STATUS current
DESCRIPTION
Nguyen, et al. Expires January 2003 [Page 16]
Internet Draft COPS-SLS July 2002
"The negotiation mode used by the client.
1 - indicates the predefined SLS mode.
2 - indicates the non-predefined SLS mode"
::= { slsNegoEntry 2 }
slsNegoMaxInt OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The maximum interval during which the client cannot issue
a REQ message to change a negotiated SLS"
::= { slsNegoEntry 3 }
slsSlsTable OBJECT-TYPE
SYNTAX SEQUENCE OF slsSlsEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"Represent an SLS"
::= { slsPolicyClasses 2 }
slsSlsEntry OBJECT-TYPE
SYNTAX SEQUENCE OF SlsSlsEntry
STATUS current
DESCRIPTION
"An instance of this class specifies an SLS"
::= { slsSlsTable 1 }
SlsSlsEntry ::= SEQUENCE {
slsSlsPrid InstanceId
slsSlsScope Prid
slsSlsFlowId Prid
slsSlsTrafficConformance Prid
slsSlsExcessTreatment Prid
slsSlsPerformance Prid
slsSlsServiceSchedule Prid
}
slsSlsPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer that uniquely identifies an instance
of the class"
::= { slsSlsEntry 1}
slsSlsScope OBJECT-TYPE
SYNTAX Prid
Nguyen, et al. Expires January 2003 [Page 17]
Internet Draft COPS-SLS July 2002
STATUS current
DESCRIPTION
" This attribute uniquely indicates where the QoS policy
for that specific service is to be enforced. The value
must point to a valid instance of one of these classes:
slsScopeParamEntry
::= { slsSlsEntry 2 }
slsSlsFlowId OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
" This attribute specifies the identification of a flow. It
indentifies a stream of IP packets sharing at least one
common characteristic. The value must point to a valid
instance of one of these classes:
slsFlowIdParamEntry"
::= { slsSlsEntry 3 }
slsSlsTrafficConformance OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
" This attribute specifies the traffic conformance of the
flow identified in slsSlsFlowId. The traffic conformance
parameters describes how the packet stream should look
like to get the guarantees indicated by the perfomance
parameters. The value must point to
a valid instance of one of these classes:
slsConformParamEntry"
::= { slsSlsEntry 4 }
slsSlsExcessTreatment OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
"This attribute specifies the excess treatment applied to
the flow identified by slsSlsFlowId if it does not conform
to parameters specified in slsSlsTrafficConformance.
Excess traffic may be dropped, shaped and/or remarked.
The value must point to a valid instance of one of these
classes:
slsExcTreatParamEntry"
::= { slsSlsEntry 5 }
slsSlsPerformance OBJECT-TYPE
SYNTAX Prid
STATUS current
Nguyen, et al. Expires January 2003 [Page 18]
Internet Draft COPS-SLS July 2002
DESCRIPTION
"This attribute specifies the performance guarantees the
network offers to the customer for the flow identified by
slsSlsFlowId. The value must point to an instance of one of
these classes:
slsPerformanceParamEntry "
::= { slsSlsEntry 6 }
slsSlsServiceSchedule OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
" This attribute indicates the start time and end time of
the service, i.e. when the service is available. The value
must point to an valid instance of one of these classes:
slsScheduleParamEntry
zeroDotZero (non specified)"
::= { slsSlsEntry 7 }
slsScopeParamTable OBJECT-TYPE
SYNTAX SEQUENCE OF slsScopeParamEntry
PIB-ACESS install-notify
STATUS current
DESCRIPTION
"This class specifies the scope parameters"
::= { slsParamClasses 1}
slsScopeParamEntry OBJECT-TYPE
SYNTAX SlsScopeParamEntry
STATUS current
DESCRIPTION
"This PRC uniquely identifies the geographical/topological
region over which the QoS is to be enforced by indicating
the boundaries of that region."
::= { slsScopeParamTable 1 }
slsScopeParamEntry ::= SEQUENCE {
SlsScopeParamPrid Prid
slsScopeParamId TagReferenceId
}
slsScopeParamPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the class."
::= { slsScopeParamEntry 1 }
Nguyen, et al. Expires January 2003 [Page 19]
Internet Draft COPS-SLS July 2002
slsScopeParamId OBJECT-TYPE
SYNTAX TagReferenceId
PIB-TAG {slsScopeIfParamId}
STATUS current
DESCRIPTION
"Identifies an SLS Scope."
::= { slsScopeParamEntry 2 }
slsScopeIfParamTable OBJECT-TYPE
SYNTAX SEQUENCE OF slsScopeInterfaceParamEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"The entry points (interfaces) of the IP packets relative
to the region (network)."
::= { slsParamClasses 2 }
slsScopeIfParamEntry OBJECT-TYPE
SYNTAX SlsScopeIfParamEntry
STATUS current
DESCRIPTION
An entry in the scope interface table describes a single
interface of the scope.
::= { slsScopeIfParamTable 1 }
slsScopeIfParamEntry ::= SEQUENCE {
SlsScopeIfParamPrid Prid
slsScopeIfParamId TagId
slsScopeIfParamIfIndex InterfaceIndex
slsScopeIfParamDirection BITS
}
slsScopeIfParamPrid OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the class."
::= { slsScopeIfParamEntry 1 }
slsScopeIfParamId OBJECT-TYPE
SYNTAX TagId
STATUS current
DESCRIPTION
"An SLS Scope is composed of one or more entry/exit
points. Each interface belonging to the same scope uses the
same Scope ID. Hence, A scope Id identifies which scope
this interface is a part of. This needs to be the value of
Nguyen, et al. Expires January 2003 [Page 20]
Internet Draft COPS-SLS July 2002
slsScopeParamId attribute for an existing instance of
slsScopeParamEntry."
::= { slsScopeIfParamEntry 2 }
slsScopeIfParamIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
STATUS current
DESCRIPTION
" This value contains the interface index of the entry/exit
interface."
::= { slsScopeIfParamEntry 3 }
slsScopeIfParamDirection OBJECT-TYPE
SYNTAX BITS{
ingress (0)
egress (1)
}
STATUS current
DESCRIPTION
" This attribute specifies whether the interface is an
entry point (ingress) or an exit point (egress) of the SLS
scope."
::= { slsScopeIfParamEntry 4 }
slsFlowIdParamTable OBJECT-TYPE
SYNTAX SEQUENCE OF slsFlowIdParamEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"This class specifies parameters identifying a traffic
stream"
::= { slsParamClasses 3 }
slsFlowIdParamEntry OBJECT-TYPE
SYNTAX SlsFlowIdParamEntry
STATUS current
DESCRIPTION
"The instance of this class identifies a traffic stream"
::= { slsFlowIdParamTable 1 }
SlsFlowIdParamEntry ::= SEQUENCE{
slsFlowIdParamPrid InstanceId
slsFlowIdParamAddrType InetAddressType,
slsFlowIdParamDstAddr InetAddress,
slsFlowIdParamDstPrefixLength InetAddressPrefixLength
slsFlowIdParamSrcAddr InetAddress,
slsFlowIdParamSrcPrefixLength InetAddressPrefixLength,
slsFlowIdParamDscp DscpOrAny,
Nguyen, et al. Expires January 2003 [Page 21]
Internet Draft COPS-SLS July 2002
slsFlowIdParamFlowLable Unsigned32,
slsFlowIdParamProtocol Integer32,
slsFlowIdParamDstL4PortMin InetPortNumber,
slsFlowIdParamDstL4PortMax InetPortNumber,
slsFlowIdParamSrcL4PortMin InetPortNumber,
slsFlowIdParamSrcL4PortMax InetPortNumber
}
slsFlowIdParamPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the class"
::= { slsFlowIdParamEntry 1 }
slsFlowIdParamAddrType OBJECT-TYPE
SYNTAX InetAddressType
STATUS current
DESCRIPTION
"Specify the type of packet's IP address."
::= { slsFlowIdParamEntry 2 }
slsFlowIdParamDstAddr OBJECT-TYPE
SYNTAX InetAddress
STATUS current
DESCRIPTION
"The IP address of the packet's destination."
::= { slsFlowIdParamEntry 3 }
slsFlowIdParamDstPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
STATUS current
DESCRIPTION
"The length of a mask for the matching of the destination
IP address. The value of 0 indicates that the address
always matches."
::= { slsFlowIdParamEntry 4 }
slsFlowIdParamSrcAddr OBJECT-TYPE
SYNTAX InetAddress
STATUS current
DESCRIPTION
"The IP address of the packet's source."
::= { slsFlowIdParamEntry 5 }
slsFlowIdParamSrcPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
Nguyen, et al. Expires January 2003 [Page 22]
Internet Draft COPS-SLS July 2002
STATUS current
DESCRIPTION
"The length of a mask for the matching of the destination
IP address. A value of 0 indicates that the address always
matches."
::= { slsFlowIdParamEntry 6 }
slsFlowIdParamDscp OBJECT-TYPE
SYNTAX DscpOrAny
STATUS current
DESCRIPTION
"The DSCP value of the packet. A value of 1 indicates that
DSCP value has not been defined."
::= { slsFlowIdParamEntry 7 }
slsFlowIdParamFlowLable OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The value of the Flow Label field in IPv6 header."
::= { slsFlowIdParamEntry 8 }
slsFlowIdParamProtocol OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The value of the Protocol field in IP header."
::= { slsFlowIdParamEntry 9 }
slsFlowIdParamDstL4PortMin OBJECT-TYPE
SYNTAX InetPortNumber
STATUS current
DESCRIPTION
"The minimum value that the packet's layer 4 destination
port number can have."
::= { slsFlowIdParamEntry 10 }
slsFlowIdParamDstL4PortMax OBJECT-TYPE
SYNTAX InetPortNumber
STATUS current
DESCRIPTION
"The maximum value that the packet's layer 4 destination
port number can have."
::= { slsFlowIdParamEntry 11 }
slsFlowIdParamSrcL4PortMin OBJECT-TYPE
SYNTAX InetPortNumber
STATUS current
Nguyen, et al. Expires January 2003 [Page 23]
Internet Draft COPS-SLS July 2002
DESCRIPTION
"The minimum value that the packet's layer 4 source port
number can have."
::= { slsFlowIdParamEntry 12 }
slsFlowIdParamSrcL4PortMax OBJECT-TYPE
SYNTAX InetPortNumber
STATUS current
DESCRIPTION
"The minimum value that the packet's layer 4 source port
number can have."
::= { slsFlowIdParamEntry 13 }
slsConformParamTable OBJECT-TYPE
SYNTAX SEQUENCE OF slsConformParamEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"This class defines the traffic conformance of a traffic
stream."
::= { slsParamClasses 4 }
slsConformParamEntry OBJECT-TYPE
SYNTAX SlsConformParamEntry
STATUS current
DESCRIPTION
"The instance of this class specifies algorithm and profile
to verify the conformance of a traffic stream"
::= { slsConformParamTable 1 }
SlsConformParamEntry ::= SEQUENCE {
slsConformParamPrid InstanceId
slsConformParamAlgo Unsigned32
slsConformParamRate Unsigned32
slsConformParamBurstSize Unsigned32
}
slsConformPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer that uniquely identifies an instance
of the class."
::= { slsConformParamEntry 1 }
slsConformParamAlgo OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
Nguyen, et al. Expires January 2003 [Page 24]
Internet Draft COPS-SLS July 2002
DESCRIPTION
"Specify the algorithm used to verify the conformance of
the traffic stream.
1 - Simple Token Bucket"
::= { slsConformParamEntry 2 }
slsConformParamRate OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The rate value used in Simple Token Bucket algorithm."
::= { slsConformParamEntry 3 }
slsConformParamBurstSize OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The burst size value used in Simple Token Bucket
algorithm."
::= { slsConformParamEntry 4 }
slsExcTreatParamTable OBJECT-TYPE
SYNTAX SEQUENCE OF slsExcTreatParamEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"This class specifies parameters of schedule of service"
::= { slsParamClasses 5 }
slsExcTreatParamEntry OBJECT-TYPE
SYNTAX SlsExctreatParamEntry
STATUS current
DESCRIPTION
"The instance of this class identifies a traffic stream"
::= { slsExcTreatParamTable 1 }
SlsExcTreatParamEntry ::= SEQUENCE {
slsExcTreatParamPrid InstanceId
slsExcTreatParamAction BITS
}
slsExcTreatParamPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer that uniquely identifies an instance
of the class."
::= { slsExcTreatParamEntry 1 }
Nguyen, et al. Expires January 2003 [Page 25]
Internet Draft COPS-SLS July 2002
slsExcTreatParamAction OBJECT-TYPE
SYNTAX BITS{
shapping(1)
-- traffic exceeding the conformance parameters
negotiated will be shaped.
dropping (2)
-- traffic exceeding the conformance parameters
negotiated will be dropped
}
STATUS current
DESCRIPTION
"Specify the treatment applied to the packet out of the
data stream's conformance negotiated
(1) shapping exceeding traffic
(2) dropping exceeding traffic"
::= { slsExcTreatParamEntry 2 }
slsPerformanceParamTable OBJECT-TYPE
SYNTAX SEQUENCE OF slsPerformanceParamEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"This class specifies parameters of performance of a flow"
::= { slsParamClasses 6 }
slsPerformanceParamEntry OBJECT-TYPE
SYNTAX SlsPerformanceParamEntry
STATUS current
DESCRIPTION
"Describes performance parameters of a flow"
::= { sls PerformanceParamTable 1 }
SlsPerformanceParamEntry ::= SEQUENCE {
slsPerformanceParamPrid InstanceId
slsPerformanceParamDelay Unsigned32
slsPerformanceParamJitter Unsigned32
slsPerformanceParamPacketLoss Unsigned32
}
slsPerformanceParamPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer that uniquely identifies an instance
of the class."
::= { slsPerformanceParamEntry 1 }
slsPerformanceParamDelay OBJECT-TYPE
Nguyen, et al. Expires January 2003 [Page 26]
Internet Draft COPS-SLS July 2002
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"Specifies the delay value in milisecond"
::= { slsPerformanceParamEntry 2 }
slsPerformanceParamJitter OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"Specifies the jitter value in milisecond"
::= { slsPerformanceParamEntry 3 }
slsPerformanceParamPacketLoss OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"Specifies the packet loss ratio in %"
::= { slsPerformanceParamEntry 4 }
slsScheduleParamTable OBJECT-TYPE
SYNTAX SEQUENCE OF slsScheduleParamEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"This class specifies parameters of schedule of service"
::= { slsParamClasses 7}
slsScheduleParamEntry OBJECT-TYPE
SYNTAX SlsScheduleParamEntry
STATUS current
DESCRIPTION
"Specifies a service schedule"
::= { slsScheduleParamTable 1 }
SlsScheduleParamEntry ::= SEQUENCE {
slsScheduleParamPrid InstanceId
slsScheduleParamStartTime ExtUTCTime
slsScheduleParamStopTime ExtUTCTime
}
slsScheduleParamPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer that uniquely identifies an instance
of the class."
::= { slsScheduleParamEntry 1 }
Nguyen, et al. Expires January 2003 [Page 27]
Internet Draft COPS-SLS July 2002
slsScheduleParamStartTime OBJECT-TYPE
SYNTAX ExtUTCTime
STATUS current
DESCRIPTION
"The time the service starts"
::= { slsScheduleParamEntry 2 }
slsScheduleParamStopTime OBJECT-TYPE
SYNTAX ExtUTCTime
STATUS current
DESCRIPTION
"The time the service terminate"
::= { slsScheduleParamEntry 3 }
slsNegoRptTable OBJECT-TYPE
SYNTAX SEQUENCE OF SlsNegoRptEntry
PIB-ACCESS report-only
STATUS current
DESCRIPTION
"This class is used by the PEP to convey negotiation
information in RPT message"
::= { slsReportClasses 1 }
slsNegoRptEntry OBJECT-TYPE
SYNTAX SlsNegoRptEntry
STATUS current
DESCRIPTION
"An instance of this class reports on the SLS negotiation"
::= { slsNegoRptTable 1 }
SlsNegoRptEntry ::= SEQUENCE {
slsNegoRptPrid InstanceId
slsNegoRptFailRea BITS
}
slsNegoRptPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer that uniquely identifies an instance
of the class"
::= { slsNEgoRptEntry 1 }
slsNegoRptFailRea OBJECT-TYPE
SYNTAX BITS {
slsNonAccepted (1)
}
STATUS current
Nguyen, et al. Expires January 2003 [Page 28]
Internet Draft COPS-SLS July 2002
DESCRIPTION
"This attribute specifies the reason by which the PEP sends
a 'failure' report
(1) the PEP does not accept the SLS suggested"
::= { slsNEgoRptEntry 1 }
END.
7. Security Considerations
COPS-SLS follows the security considerations for COPS protocol [COPS]
8. IANA Consideration
The client-type value of COPS-SLS is to be assigned through IANA.
9. Acknowledgements
We would like to acknowledge ours friends from LIP6 or INFRES-ENST
for their comments and discussions during the preparation of this
document.
10. References
[COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Raja, A.
Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[COPS-PR] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie,
S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, "COPS
Usage for Policy Provisioning (COPS-PR)", RFC 3084,
March 2001.
[DS-TERM] D. Grossman, "New Terminology for Diffserv", draft-
ietf-diffserv-new-terms-08.txt, January 2002, Work in
progress.
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy Based Admission Control", RFC
2753, January 2000.
[RFC-2026] S. Bradner, " The Internet Standards Process --
Revision 3", RFC 2026, October 1996.
[RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[SLS-AQU] S. Salsano, F. Ricciato, M. Winter, G. Eichler, A.
Nguyen, et al. Expires January 2003 [Page 29]
Internet Draft COPS-SLS July 2002
Thomas, F. Fuenfstueck, T. Ziegler, C. Brandauer,
"Definition and usage of SLSs in the AQUILA
consortium", draft-salsano-aquila-sls-00.txt, November
2000, Work in pogress.
[SLS-TEQ] D. Goderis, Y. T'Joens, C. Jacquenet, G. Memenios, G.
Pavlou, R. Egan, D. Griffin, P. Georgatsos, L.
Georgiadis, P.V. Heuven, "Service Level Specification
Semantics and parameters", draft-tequila-sls-01.txt,
June 2001, Work in progress.
[SPPI] K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn,
R. Sahita, A. Smith, F. Reichmeyer, "Structure of
Policy Provisioning Information (SPPI)", RFC 3159,
August 2001.
[SESSION-AUTH]L-N. Hamer, B. Gage, "Framework for session setup with
media authorization", Internet-Draft, draft-ietf-rap-
session-auth-03.txt, June 2002, Work in progress.
[COPS-FRWK] K. Chan, L-N. Hamer, "An Architecture for COPS Based
Policy Control Management Framework COPS Framework,
draft-ietf-rap-cops-frwk-01.txt, June 2002, work in
progress.
[SMIv2] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case,
K. McCloghrie, M. Rose, S. Waldbusser, " Structure of
Management Information Version 2 (SMIv2)", RFC 2578,
April 1999.
[INET-ADDR] M. Daniele, B. Haberman, S. Routhier and J.
Schoenwaelder, "Textual Conventions for Internet
Network Addresses", draft-ietf-ops-rfc2851-update-
06.txt, December 2001.
12. Authors' Addresses
Thi Mai Trang Nguyen
Ecole Nationale Superieure des Telecommunications
Departement Informatique-Reseaux
46 Rue Barrault
74013 Paris - FRANCE
Phone: +33 1 45 81 74 61
Email: trnguyen@enst.fr
Nadia Boukhatem
Ecole Nationale Superieure des Telecommunications
Department Informatique-Reseaux
Nguyen, et al. Expires January 2003 [Page 30]
Internet Draft COPS-SLS July 2002
46 Rue Barrault
74013 Paris - FRANCE
Phone: +33 1 45 81 82 16
Email: Nadia.Boukhatem@enst.fr
Yacine El Mghazli
Alcatel R&I
Route de Nozay
F-91460 Marcoussis - FRANCE
Phone: +33 1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr
Nathalie Charton
Alcatel R&I
Route de Nozay
F-91460 Marcoussis - FRANCE
Phone: +33 1 69 63 14 85
Email: Nathalie.Charton@ms.alcatel.fr
Louis-Nicolas Hamer
Nortel Networks
Ottawa, Canada
Email: nhamer@nortelnetworks.com
Guy Pujolle
University of Pierre et Marie Curie
Laboratoire d'Informatique de Paris 6
8 Rue du Capitaine Scotte
75015 Paris - FRANCE
Phone: +33 1 44 27 75 14
Email: Guy.Pujolle@lip6.fr
12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Nguyen, et al. Expires January 2003 [Page 31]
Internet Draft COPS-SLS July 2002
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Nguyen, et al. Expires January 2003 [Page 32]