Internet DRAFT - draft-cpr-rap-cops-maid
draft-cpr-rap-cops-maid
WG: Resource Allocation Protocol (RAP) Gino Carrozzo
Internet Draft Nicola Ciulli
Giacomo Sergio
Document: draft-cpr-rap-cops-maid-00.txt CPR
Expires: April 2004 November 2003
COPS-MAID: COPS Usage for Multi-Access Inter-Domain
MPLS-DiffServ Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This document describes an architecture for the communication between
Border Routers (BR) and a Bandwidth Broker (BB) in a MPLS/DiffServ
core network. This architecture is based on the Common Open Policy
Service (COPS) protocol and defines a new Client Type extension for
it.
This specification applies basically to intra-domain MPLS/DiffServ
network scenarios. However, the same extensions to COPS are suitable
for inter-domain communications, when MPLS Label Switched Paths (LSP)
with QoS-DiffServ guarantees are established across multiple
MPLS/DiffServ islands. Therefore, this document provides also a
simple and efficient model for inter-BB communication.
Carrozzo, et al. Expires û April 2004 [Page 1]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
The new COPS client type provides a unified semantic to unify the
specific parameters of the different access protocols towards the
Policy Decision Point (PDP) on the BB, allowing the use of a single
PEP type implementation despite of the adopted access protocol.
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 [2].
Table of Contents
1. Network Model..................................................3
2. COPS-MAID extensions...........................................5
2.1 Client Type................................................5
2.2 Context Object.............................................5
2.3 COPS-MAID Protocol Objects Format..........................6
2.4 Request ID Object..........................................6
2.5 Source Host IPv4 address Object............................7
2.6 Destination IPv4 address Object............................7
2.7 Source Host IPv6 address Object............................7
2.8 Destination IPv6 address Object............................8
2.9 IPv4 Ingress Border Router Interface Object/TrunkID........8
2.10 IPv6 Ingress Border Router Interface Object/TrunkID.......9
2.11 Egress Border Router Interface Object.....................9
2.12 IPv6 Egress Border Router Interface Object...............10
2.13 Traffic Type Object......................................10
2.14 Traffic Characterization Object..........................11
2.15 QoS Class Description Object.............................15
2.16 QoS Parameters Description Object........................15
2.17 LSP Recovery description Object..........................16
2.18 COPS-MAID Decision Object................................17
2.19 Temporal information object..............................17
2.20 Explicit Route object....................................18
2.21 Reject Reason Object.....................................21
3. COPS-MAID Client Specific Information Object..................21
3.1 COPS-MAID Client Specific RAR data........................21
3.2 COPS-MAID Client Specific Decision data...................22
4. Message content...............................................23
4.1 Request Message (REQ) PEP -> PDP..........................23
4.2 Decision Message (DEC) PDP -> PEP.........................23
4.3 Report State Message (RPT) PEP -> PDP.....................23
Security Considerations..........................................23
References.......................................................24
Acknowledgments..................................................24
Author's Addresses...............................................24
Carrozzo, et al. Expires - Aprily 2004 [Page 2]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
1. Network Model
COPS (Common Open Policy Service) [3]is a simple query and response
protocol that can be used to exchange policy information in an
administrative domain. Relying on the client-server model, COPS
architecture is based on two fundamental elements: a policy server,
called Policy Decision Point (PDP), also addressed as COPS server,
and one or more policy clients, called Policy Enforcement Points
(PEPs), addressed as COPS clients. At least one policy server must
exist in each administrative domain, in order to implement a complete
COPS communication with one or more PEPs.
A single PEP is able to support multiple client-types, and it may
send multiple Client-Open messages to the PDP, each specifying a
particular client-type to a PDP over one or more TCP connections. If
a client-type is not supported by the PDP, the PDP itself can
redirect the PEP to an alternative PDP address and port for a given
client-type via COPS.
In an advisable network scenario the peripheral non-DiffServ access
networks (IntServ networks with the RSVP, H.323, SIP, MPEG-4, etc.)
are connected to a MPLS/DiffServ core network. In such a network ERs
and BRs manage the interoperability between different domains: in our
proposal the functionality of both devices are unified in a single
element called MA-BR, where MA identifies a generic Multi-Access
network architecture.
The data plane provides the mapping and forwarding of the access
network flows into the proper DiffServ PHBs/LSPs(labels) and vice
versa.
The control plane is responsible for Admission Control (AC) and
policy decisions (taken on a per-flow or per-PHB basis) and for the
service level agreement (SLA) maintenance.
Our proposal for such a control plane is to provide the MA-BR
communication with BB by means of the COPS protocol, because of the
great flexibility it provides and of the encapsulation capability for
client-specific information in COPS messages.
The MA-BR may either delegate all AC and policy decisions to the BB,
working in a totally outsourcing scenario, or may have limited local
AC and policy functionality, granted by a provisioning scenario. In
any case BB has pre-emption rights on each MA-BR decision. According
to the COPS architecture [3], the MA-BR must provide an interface to
the BB (i.e. the COPS client, or PEP) to send requests, accept
decisions and periodically report its status.
The BB, which is able to monitor the network status works as an
"oracle", performs the centralized AC and policy functionality.
It is possible (e.g. in MPLS Core Networks) that the BB configures
core and border elements according to its choices, achieving traffic
engineering capabilities. The BB, in its turn, must provide the MA-BR
with an interface to accept requests and send decisions (i.e. the
PDP, or COPS server) and should have one or more interfaces towards
the core network, in order to collect statistics and configure the
devices.
Carrozzo, et al. Expires - Aprily 2004 [Page 3]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
As previously addressed, it is desirable to tune an optimum mix of
dynamical and static resource allocation in order to share
architectural complexity between BB module and border NEs and make
the system scalable.
Our proposal focuses on the possibility of integrating different
protocols used in the access network. In a general scenario,
applications speaking different signalling protocols may coexist, and
the access point of the Core Network, i.e. the MA-BR, must understand
all these languages. According to the COPS architecture, different
applications using different protocols may be viewed as different
client types.
A client type is already defined for the integration of RSVP and COPS
[4], where RSVP is COPS client-type 1. The proposed standard has some
weak points due to the nature of RSVP itself, e.g. the duplication of
the states installed both in PDP and in PEP which limits the
scalability of the model and the possibility of expanding the core
domain. A possible solution to this scalability problem is an
administrative domain with many PDP supporting one or few client-
types each.
Whenever a PEP sends a client-open message to a PDP, that does not
support that client-type, it has the capability to redirect the PEP
to the right PDP. This solution is more scalable but needs to
implement many COPS servers, one for each of the supported client-
types within the domain. All these COPS servers have to exchange
management information to perform a coherent resource allocation, or
they must query for a higher level "omniscient" BB.
We propose to develop a unified COPS semantic in order to integrate
all the different protocols supported by the access domain. This
semantic will encapsulate the client-specific information in a common
format besides of the specific protocol.
By means of this modified architecture it is possible to reduce the
complexity of the system.
The MA-BR traduces the incoming requests in a common format:
- a unified COPS client-type transmits all the information to the
PDP;
- it is no longer needed to develop a different COPS server (PDP)
for each supported COPS client;
- there is no need to refer to a higher-level device when
performing resource allocation because the unique COPS server
(PDP) could be located inside the BB itself.
For this purpose, a new client-type, the COPS-MAID client type, is
defined in the following sections. This client-type is used to
transport admission control messages despite of the signalling
protocol (e.g. RSVP, SIP, H.323) and of the QoS/TE architecture (e.g.
DiffServ/MPLS). Therefore a single client could be supported by the
PDP shifting the complexity on the border router where appropriate
Inter Working Units (IWUs) are used to map protocol specific messages
into generalized client messages.
Carrozzo, et al. Expires - Aprily 2004 [Page 4]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
In order to provide a correct policy decision and perform admission
control, the BB MUST know the following information:
- Traffic origin:
> host which originated the flow;
> BR interface where the traffic will pass through;
- Traffic direction:
> egress BR for the flow;
> core routers the flow will go across (got from a Path
Computation System);
- Traffic type:
> traffic characterization;
> QoS parameters;
- Temporal information (optional)
> start time, end time, repetition intervals;
Besides of the specific signalling protocol used by the clients, a
subset of these information MUST be passed from the PEP to the PDP by
means of the COPS-MAID client type, while the remaining ones will be
somehow learned by the BB (e.g. via SNMP).
2. COPS-MAID extensions
The meaning and usage of several COPS objects is affected when used
with the COPS-MAID client type. This section describes these objects
and their usage.
2.1 Client Type
COPS-MAID is COPS client-type TBD.
2.2 Context Object
The semantics of the Context object for COPS-MAID is as follows:
- R-Type (Request Type Flag)
> R-Type = 0x01: Incoming-Message/Admission Control Requests;
> R-Type = 0x02: Resource Allocation Request;
> R-Type = 0x08: Configuration request;
For the COPS-MAID client-type the R-Type flag 0x04 (Outgoing-Message
Request) is not used.
- M-Type (Message Type)
> M-Type = 0x01: Add request;
> M-Type = 0x02: Release request;
> M-Type = 0x03: Modify request;
Carrozzo, et al. Expires - Aprily 2004 [Page 5]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
2.3 COPS-MAID Protocol Objects Format
All the objects described in this section have to be intended as
objects/attributes encapsulated within other "higher level" COPS
objects. In particular, they are carried in the COPS-MAID Client
Specific Information Object (ref. 3.1) for the PEP -> PDP
communication, and in the Client Specific Decision Object (ref. 3.2)
for the PDP -> PEP direction.
These COPS-MAID objects have a TLV format (Type-Length-Value) where
Type (16 bit) identifies univocally the object, Length (16 bit)
indicates the length of the object in Bytes (including the header)
and Value is the content of the object.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.4 Request ID Object
This object is carried in the Client Specific Information Object of a
Request Message sent from a PEP to a PDP, or in the Client Specific
Decision data sent from a PDP to a PEP. It allows to bind requests
sent by the PEP and having the same COPS Handle Object with responses
coming from the PDP (see [4]). This mechanism allows an COPS-MAID PEP
to make more than one request for a specific state (identified by the
Handle Object) before receiving a PDP response.
The Request ID Object is chosen by the PEP and it is opaque to the
PDP. For each request a different Request ID is chosen by the PEP.
Request ID values can be reused if they are associated to different
Handle Objects.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In case of PCS enabled on BB, the Request ID / source MA-BR address
pair provides a unique identifier for the path computation which
returns an ERO for the RSVP-TE signalling.
Carrozzo, et al. Expires - Aprily 2004 [Page 6]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
2.5 Source Host IPv4 address Object
This object specifies the IPv4 address of the host originating the
flow for which a PDP decision is requested. It is carried in the
Client Specific Information Object of a Request Message sent from a
PEP to a PDP or in the Client Specific Decision data sent from a PDP
to a PEP. The host IP address could be useful to the Bandwidth Broker
in order to perform Authorization operations.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Host IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.6 Destination IPv4 address Object
This object specifies the IPv4 address of the host which is the
destination of the flow that requires a PDP decision. It is carried
in the Client Specific Information Object of a Request Message sent
from a PEP to a PDP or in the Client Specific Decision data sent from
a PDP to a PEP.
The destination address is needed each time the BR is not aware of
the egress router for the traffic flow for which is performing the
request. Moreover, the destination address could be useful to the
Bandwidth Broker in order to perform flow authorization operations.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Host IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.7 Source Host IPv6 address Object
This object specifies the IPv6 address of the host originating the
flow for which a PDP decision is requested. It is carried in the
Client Specific Information Object of a Request Message sent from a
PEP to a PDP or in the Client Specific Decision data sent from a PDP
to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Carrozzo, et al. Expires - Aprily 2004 [Page 7]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
| Source Host IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.8 Destination IPv6 address Object
This object specifies the IPv6 address of the host, which is the
destination of the flow that requires a PDP decision. It is carried
in the Client Specific Information Object of a Request Message sent
from a PEP to a PDP or in the Client Specific Decision data sent from
a PDP to a PEP.
The destination address is needed each time the BR is not aware of
the egress router for the traffic flow for which is performing the
request.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination Host IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.9 IPv4 Ingress Border Router Interface Object/TrunkID
This object specifies the IPv4 address of the ingress border router
output interface for the traffic flow which requires resource
allocation.
It is carried in the Client Specific Information Object of a Request
Message sent from a PEP to a PDP or in the Client Specific Decision
data sent from a PDP to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress BR Output IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label Type field is used to specify the semantics of the
following label object:
Carrozzo, et al. Expires - Aprily 2004 [Page 8]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
- Label Type = 0x00000001: DiffServ;
- Label Type = 0x00000002: MPLS;
- Label Type = 0x00000003: ATM;
- Label Type = TBA;
The Label object specifies an identifier for the traffic flow with
respect to the specified semantic type (e.g. a DSCP in case of
DiffServ semantics, a label in case of MPLS, etc.). The couple IPv4
output address/label identifies univocally the trunk where the
traffic flow has to be aggregated.
2.10 IPv6 Ingress Border Router Interface Object/TrunkID
This object specifies the IPv6 address of the ingress border router
output interface for the traffic flow which requires resource
allocation. It is carried in the Client Specific Information Object
of a Request Message sent from a PEP to a PDP or in the Client
Specific Decision data sent from a PDP to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Ingress BR Output IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label Type field is used to specify the semantics of the label:
- Label Type = 0x00000001: DiffServ;
- Label Type = 0x00000002: MPLS;
- Label Type = 0x00000003: ATM;
- Label Type = TBA
The Label value is set according to the specified Label Type.
2.11 Egress Border Router Interface Object
This object specifies the IPv4 Egress Border Router interface address
for the traffic flow for which the resource allocation request is
performed. It is carried in the Client Specific Information Object of
Carrozzo, et al. Expires - Aprily 2004 [Page 9]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
a Request Message sent from a PEP to a PDP or in the Client Specific
Decision data sent from a PDP to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress BR Input IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.12 IPv6 Egress Border Router Interface Object
This object specifies the IPv6 Egress Border Router interface address
for the traffic flow for which the resource allocation request is
performed. It is carried in the Client Specific Information Object of
a Request Message sent from a PEP to a PDP or in the Client Specific
Decision data sent from a PDP to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Egress BR Input IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.13 Traffic Type Object
Traffic Type IDs are maintained in the form of a list where each
Traffic Type ID value corresponds to a predefined (either
standardized or client defined) characterization: Traffic Type ID =
value -> characterization.
- Traffic Type ID = TBA
- Traffic Type ID = TBA
Traffic Type Object and Traffic Characterization Object, described in
the next paragraph, can be used together or separately, allowing to
specify traffic parameters at different levels.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo, et al. Expires - Aprily 2004 [Page 10]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
2.14 Traffic Characterization Object
The traffic characterization object describes the traffic
characterization parameters for the traffic flow. It is carried in
the Client Specific Information Object of a Request Message sent from
a PEP to a PDP or in the Client Specific Decision data sent from a
PDP to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length = var |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | MPLS/DS TSpec number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS/DS Tspec sub-objects |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Resource affinities are declared by three 32 bit masks:
- Exclude-any (32-bit), for the set of attribute filters associated
with a tunnel any of which renders a link unacceptable;
- Include-any (32-bit), for the set of attribute filters
associated with a tunnel any of which renders a link acceptable)
- Include-all (32-bit), for the set of attribute filters
associated with a tunnel all of which must be present for a link
to be acceptable.
Priorities for the flow is specified by:
- Setup Priority (in the range of 0 to 7), which specifies
priority of the session with respect to taking resources;
- Holding Priority (in the range of 0 to 7), which specifies
priority of the session with respect to holding resources;
The MPLS/DS TSpec number specifies the total number of MPLS/DS
Traffic Specification entries (sub-objects) contained in the object.
Each sub-object is structured as follows:
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | DS Behaviour Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Profile Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo, et al. Expires - Aprily 2004 [Page 11]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
| Profile Characterization |
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Types for MPLS/DS Tspec sub-object are:
- Type = 0x0001: E-LSP Tspec;
- Type = 0x0002: L-LSP Tspec;
and depending on Type value the DS Behaviour Class field contains the
EXP value (3 bit û left aligned) or the PHBID field (16 bit, ref.
[5]).
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | EXP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The Traffic Profile Type value specifies the type of characterization
attached to the object.
The following characterization type are supported:
- Traffic Profile Type 1 = 0x00000001: Average & Peak Rate (r, p,
m, M);
- Traffic Profile Type 2 = 0x00000002: LBAP point (r, b, p, m, M,
avgr);
- Traffic Profile Type 3 = 0x00000003: 3D LBAP point (l, r, b, p,
M, avgr);
- Traffic Profile Type 4 = 0x00000004: LBAP plot (p, m, M, avgr,
(r, b), ... , (r, b));
- Traffic Profile Type 5 = 0x00000005: 3D-LBAP plot (p, m, M,
avgr, (l, (r,b) plot,...,
l, (r,b)plot));
where r indicates the rate (bytes/s), b the bucket size (bytes), p
the peak rate (bytes/s), m the minimum policed unit (bytes), M the
connection MTU (bytes), avgr the average rate (bytes/sec) and l the
loss probability.
Carrozzo, et al. Expires - Aprily 2004 [Page 12]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
2.14.1 Profile Characterization for Type 1
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.14.2 Profile Characterization for Type 2
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.14.3 Profile Characterization for Type 3
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Probability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo, et al. Expires - Aprily 2004 [Page 13]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
2.14.4 Profile Characterization for Type 4
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.14.5 Profile Characterization for Type 5
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Probability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo, et al. Expires - Aprily 2004 [Page 14]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
| Loss Probability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.15 QoS Class Description Object
This object specifies the QoS class to which the traffic flow belongs
to. Four different QoS classes are defined:
- Class Type = 0x00000001: bounded losses;
- Class Type = 0x00000002: guaranteed bandwidth;
- Class Type = 0x00000003: guaranteed bandwidth + bounded delay;
- Class Type = 0x00000004: guaranteed bandwidth + bounded delay +
bounded jitter.
Each one of this classes has more stringent QoS guarantees than the
previous class.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.16 QoS Parameters Description Object
This object defines the QoS parameters requested. Four different
parameters are defined:
- bandwidth;
- delay;
- jitter;
- loss probability;
For each of the previous parameters a slack term could be indicated:
while the bandwidth slack term must be subtracted to the bandwidth
parameter in order to find the minimum allowed bandwidth, the jitter
Carrozzo, et al. Expires - Aprily 2004 [Page 15]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
and delay slack terms must be added to the respective parameters in
order to find the maximum allowed delay and jitter.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth (bytes/sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Slack term |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter (msec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter Slack term |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay (msec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Slack term |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.17 LSP Recovery description Object
This object is used by the PEP to request by the way of a PDP a Path
Computation System (PCS) to compute a pair of Explicit Route objects
for a traffic flow. It is carried in the Client Specific Resource
Allocation Request data Object of a Decision Message sent from a PDP
to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery type | Recovery diversity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values defined for recovery type are:
- Recovery type = 0x0000: Unprotected
- Recovery type = 0x0001: Path Protection
- Recovery type = 0x0002: Link Protection
- Recovery type = 0x0003: Path Fast-Restoration (with preplanning
of a backup ERO)
- Recovery type = 0x0004: Link Fast-Restoration (with preplanning
of a partial detour for each link)
- Recovery type = TBA
Values defined for recovery diversity are:
- Recovery diversity = 0x0000: None
- Recovery diversity = 0x0001: Node
- Recovery diversity = 0x0002: Link
Carrozzo, et al. Expires - Aprily 2004 [Page 16]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
- Recovery diversity = 0x0003: SRLG
- Recovery diversity = TBA
2.18 COPS-MAID Decision Object
This object is used by the PDP to inform the PEP how to aggregate the
flow. It is carried in the Client Specific Decision Data Object of a
Decision Message sent from a PDP to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 15 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label Type field is used to specify the semantics of the label:
- Label Type = 0x00000001: DiffServ;
- Label Type = 0x00000002: MPLS;
- Label Type = 0x00000003: ATM;
- Label Type = TBA;
The Label value is set according to the specified Label Type.
2.19 Temporal information object
The temporal information object is used to specify the time interval
inside which the request is valid. It is carried in the Client
Specific Information Object of a Request Message sent from a PEP to a
PDP or in the Client Specific Decision data sent from a PDP to a PEP.
y means of this object one or more time intervals and/or periodically
repeated time intervals could be defined.
An ASCII string is used to describe the temporal information. If the
string length is not multiple of 32 bits appropriate zero padding
bytes are used.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =16 | Length = var |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCII String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo, et al. Expires - Aprily 2004 [Page 17]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
The ASCII string is in the form:
{[<start date _ end date>
<start day of the week _ end day of the week>
<start hour _ end hour>]
[<start date _ end date>
<start day of the week _ end day of the week>
<start hour _ end hour>]
...
[<start date _ end date>
<start day of the week _ end day of the week>
<start hour _ end hour>]
}
where:
- start date and end date are in the format: "ddmmyyyy";
- start day of the week and end day of the week are expressed by
one of the following character: A-B-C-D-E-F-G. The letters are
the coding for: sun - mon - tue - wen - thu - fri - sat ,
respectively;
- start hour and end hour are in the format: "hhmm".
Blanks, present in the string above, are used for increase the
readability, and are suppressed in the TempInfo object value.
The ASCII string starts with "{" and ends with "}". Each time
interval is specified internally to the characters "[" and "]". This
time interval is the intersection of the time intervals (separated by
the character "-") specified internally to the characters "<" and
">". Otherwise the global time interval is the union of all the time
intervals specified internally to the characters "[" and "]". The
character ("*") is used as wildcard.
As an example, the ASCII string
{[<15092001-15122001><B-C-F><1600-1800>]
[<01042002-30062002><*><1700-1900>]}
means: every Monday, Wednesday and Friday between September the 15th
and December the 15th 2001, from 16:00 to 18:00 and everyday between
April the 1st and June the 30th 2002, from 17:00 to 19:00. This
string could be, e.g , used to perform a resource allocation request
for a tele-teaching scenario.
2.20 Explicit Route object
The contents of an Explicit Route object are a series of variable-
length data items called sub-bjects. An explicit route is a
particular path in the network topology. An explicit route is
described as a list of groups of nodes along the explicit route. In
addition to the ability to identify specific nodes along the path, an
explicit route can identify a group of nodes (called abstract node)
Carrozzo, et al. Expires - Aprily 2004 [Page 18]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
that must be traversed along the path. This capability allows the
routing system a significant amount of local flexibility in
fulfilling a request for an explicit route. This capability allows
the generator of the explicit route to have imperfect information
about the details of the path.
The explicit route is encoded as a series of sub-objects contained in
an ERO object. Each sub-object identifies a group of nodes in the
explicit route. An explicit route is thus a specification of groups
of nodes to be traversed.
This object is used by the PDP to inform the MA-BR signalling
protocol for the core network how to setup an LSP. It is carried in
the Client Specific Decision Data Object of a Decision Message sent
from a PDP to a PEP.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 17 | Length = var |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| Sub-objects |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.20.1 ERO Sub-objects
Each sub-object has the form:
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length = var | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ... |
| Sub-object contents |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L bit is an attribute of the sub-object. The L bit is set if the
sub-object represents a loose hop in the explicit route. If the bit
is not set, the sub-object represents a strict hop in the explicit
route. The path between a strict node and its preceding node MUST
include only network nodes from the strict node and its preceding
abstract node. The path between a loose node and its preceding node
MAY include other network nodes that are not part of the strict node
or its preceding abstract node.
The Type indicates the type of contents of the sub-object. Currently
defined values are:
- Type = 0x01: IPv4 prefix
- Type = 0x02: IPv6 prefix
- Type = 0x20: Autonomous system number
Carrozzo, et al. Expires - Aprily 2004 [Page 19]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
The Length contains the total length of the sub-object in bytes,
including the L, Type and Length fields. The Length MUST be at least
4, and MUST be a multiple of 4.
2.20.1.1 Sub-object 1: IPv4 prefix
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 0x01 | Length = 8 | Ingress i/f IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress i/f IPv4 addr (contd) | Prefix length | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ingress interface IPv4 address (32) is treated as a prefix based
on the prefix length (8 bit) value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
Note that a prefix length of 32 indicates a single IPv4 node.
2.20.1.2 Sub-object 1: IPv6 prefix
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 0x02 | Length = 20 | Ingress i/f IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress i/f IPv6 addr (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress i/f IPv6 addr (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress i/f IPv6 addr (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress i/f IPv4 addr (contd) | Prefix length | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ingress interface IPv6 address (128) is treated as a prefix based
on the prefix length (8 bit) value below. Bits beyond the prefix are
ignored on receipt and SHOULD be set to zero on transmission.
Note that a prefix length of 128 indicates a single IPv6 node.
2.20.1.3 Sub-object 32: Autonomous System Number
The contents of an Autonomous System (AS) number sub-object are a 4-
octet AS number. The abstract node represented by this sub-object is
the set of nodes belonging to the autonomous system.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 0x20 | Length = 8 | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo, et al. Expires - Aprily 2004 [Page 20]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
2.21 Reject Reason Object
This object specifies the reason of a negative answer coming from the
PDP. It is carried in the Client Specific Decision Data Object of a
Decision Message sent from a PDP to a PEP.
Reason Code:
- Reason Code = 0x00000001: Resource unavailable;
- Reason Code = 0x00000002: Unsupported Traffic Type;
- Reason Code = 0x00000003: Unacceptable Src Address;
- Reason Code = 0x00000004: Unacceptable Dst Address;
- Reason Code = 0x00000005: Invalid Traffic Parameters;
- Reason Code = 0x00000006: No primary route to host;
- Reason Code = 0x00000007: No backup route to host;
- Reason Code = 0x00000008: No diversity for backup route;
- Reason Code = ....
3. COPS-MAID Client Specific Information Object
3.1 COPS-MAID Client Specific RAR data
The COPS-MAID Client Specific Resource Allocation Request data (RAR)
is carried in the REQ messages for the COPS-MAID client and contains
the description of the resources and has a different format depending
on whether the type of request is Add/Release or Modify.
For Add and Release messages the COPS-MAID ClientSI RAR is:
<ClientSI: COPS-MAID RAR data>::= <ReqID>
[<SrcIPv4(s)>]
[<SrcIPv6(s)>]
[<DstIPv4(s)>]
[<DstIPv6(s)>]
[<IPv4BRIf(s)>]
[<IPv6BRIf(s)>]
[<IPv4ER(s)>]
[<IPv6ER(s)>]
[<Ttype(s)>]
[<TDesc(s)>]
[<QoSDesc(s)>]
[<QoSPrms(s)>]
[<Recov(s)>]
[<TempInfo(s)>]
with:
X(s) ::= <X> | <X> <X>
whether for the Modify messages is:
Carrozzo, et al. Expires - Aprily 2004 [Page 21]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
<ClientSI: COPS-MAID RAR data> ::= <ReqID>
[<SrcIPv4(s)>] (new)
[<SrcIPv4(s)>] (old)
[<SrcIPv6(s)>](new)
[<SrcIPv6(s)>] (old)
[<IPv4BRIf(s)>](new)
[<IPv4BRIf(s)>](old)
[<IPv6BRIf(s)>](new)
[<IPv6BRIf(s)>](old)
[<IPv4ER(s)>](new)
[<IPv4ER(s)>](old)
[<IPv6ER(s)>] (new)
[<IPv6ER(s)>] (old)
[<Ttype(s)>] (new)
[<Ttype(s)>] (old)
[<TDesc(s)>] (new)
[<TDesc(s)>] (old)
[<QoSDesc(s)>] (new)
[<QoSDesc(s)>] (old)
[<QoSPrms(s)>] (new)
[<QoSPrms(s)>] (old)
[<Recov(s)>] (new)
[<Recov(s)>] (old)
[<TempInfo(s)>] (new)
[<TempInfo(s)>] (old)
3.2 COPS-MAID Client Specific Decision data
The COPS-MAID ClientSI Decision data is carried in the COPS decision
message and contains the PDP decision for a certain Request ID.
<Client SI: COPS-MAID Decision data> ::= <Request ID>
< COPS-MAIDDec> | < RejRea>
[<SrcIPv4(s)>]
[<SrcIPv6(s)>]
[<IPv4BRIf(s)>]
[<IPv6BRIf(s)>]
[<IPv4ER(s)>]
[<IPv6ER(s)>]
[<Ttype(s)>]
[<TDesc(s)>]
[<QoSDesc(s)>]
[<QoSPrms(s)>]
[<TempInfo(s)>]
[<ERO(s)>] - primary
[<ERO(s)>] û backup
Carrozzo, et al. Expires - Aprily 2004 [Page 22]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
4. Message content
4.1 Request Message (REQ) PEP -> PDP
<Request> ::= <Common Header>
<Client Handle>
<Context = Resource-Allocation request>
[<IN-Int>]
[<OUT-Int>]
[<ClientSI: COPS-MAID RAR data>]
[<Integrity>]
4.2 Decision Message (DEC) PDP -> PEP
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision> | <Error>
[<Integrity>]
<Decision>::= <Context = Resource-Allocation request>
<Decision: Flags>
<Decision: COPS-MAID decision data>
4.3 Report State Message (RPT) PEP -> PDP
The RPT Message is sent by the PEP to PDP in case of problems with a
received Decision Message.
RPT Message has the following format:
<Decision Message> ::= <Common Header>
<Client Handle>
<Report Type>
<Client SI: COPS-MAID RPT data>
[<Integrity>]
<Client SI: COPS-MAID RPT data> ::= <Request ID>
Security Considerations
The extensions proposed in this document do not raise any new
security concerns with respect to those declared in [3].
Carrozzo, et al. Expires - Aprily 2004 [Page 23]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A.
Sastry, "The COPS (Common Open Policy Service) Protocol", IETF RFC
2748, January 2000
4 S. Herzdog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A.
Sastry, "COPS Usage for RSVP", IETF RFC 2749, January 2000
5 D.Black, S. Brim, B. Carpenter, F. Le Faucheur, ôPer Hop Behavior
Identification Codeö, RFC 3140, June 2001
Acknowledgments
The authors would like to thank G. Giorgi and F. Mustacchio for their
comments on this draft.
Author's Addresses
Gino Carrozzo
META Centre - Consorzio Pisa Ricerche
c.so Italia, 116
56125 Pisa, ITALY
Email: g.carrozzo@cpr.it
Nicola Ciulli
META Centre - Consorzio Pisa Ricerche
c.so Italia, 116
56125 Pisa, ITALY
Email: n.ciulli@cpr.it
Giacomo Sergio
META Centre - Consorzio Pisa Ricerche
c.so Italia, 116
56125 Pisa, ITALY
Email: g.sergio@cpr.it
Carrozzo, et al. Expires - Aprily 2004 [Page 24]
Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003
Intellectual Property Rights Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
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.
Carrozzo, et al. Expires - Aprily 2004 [Page 25]
