Internet DRAFT - draft-carrozzo-aaa-cops-maid
draft-carrozzo-aaa-cops-maid
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
WG: Authentication, Authorization and
Accounting (AAA) Gino Carrozzo
Internet Draft Nicola Ciulli
Gianluca Insolvibile
Giacomo Sergio
Document: draft-carrozzo-aaa-cops-maid-00.txt CPR
Expires: November 2005 May 2005
COPS-MAID: COPS Usage for Multi-Access Inter-Domain
Service Provider Networks based on MPLS-Diffserv
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This specification defines some extensions to the COPS protocol under
the COPS-MAID client type to be used for the SP Control Plane
Carrozzo et al. Expires - November 2005 [Page 1]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
procedures in a Multimedia Telephony Service (MTS) context. The
reference SP network infrastructure is assumed to be based on
MPLS/Diffserv Control and Data Planes. The proposed architecture is
defined signalling independent because it is able to uphold different
signalling protocols used by the MTS-enabled terminals (e.g. SIP,
H.323, H.248-Megaco, MGCP, etc.) with a common approach. The overall
specification relies on the identification of a common and
generalized semantic for the service requests (policy & CAC), which
will encapsulate the client-specific information in a common format
besides of the specific protocol (e.g. SIP, H.323, etc.).
By means of this generalized architecture it is possible to reduce
the complexity of the SP Control Plane architecture.
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. Introduction...................................................3
2. MAID network architecture......................................4
3. The COPS-MAID rationale........................................6
4. COPS-MAID extensions...........................................7
4.1 Client Type................................................7
4.2 Context Object.............................................8
4.3 COPS-MAID Protocol Objects Format..........................8
4.4 Request ID Object..........................................8
4.5 Source Host IPv4 address Object............................9
4.6 Destination IPv4 address Object............................9
4.7 Source Host IPv6 address Object...........................10
4.8 Destination IPv6 address Object...........................10
4.9 IPv4 Ingress Border Router Interface Object/TrunkID.......10
4.10 IPv6 Ingress Border Router Interface Object/TrunkID......11
4.11 Egress Border Router Interface Object....................12
4.12 IPv6 Egress Border Router Interface Object...............12
4.13 Traffic Type Object......................................12
4.14 Traffic Characterization Object..........................13
4.15 QoS Class Description Object.............................17
4.16 QoS Parameters Description Object........................18
4.17 LSP Recovery description Object..........................18
4.18 COPS-MAID Decision Object................................19
4.19 Temporal information object..............................20
4.20 Explicit Route object....................................21
4.21 Reject Reason Object.....................................23
5. COPS-MAID Client Specific Information Object..................23
Carrozzo et al. Expires - November 2005 [Page 2]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
5.1 COPS-MAID Client Specific RAR data........................24
5.2 COPS-MAID Client Specific Decision data...................25
6. Message content...............................................25
6.1 Request Message (REQ) PEP -> PDP..........................25
6.2 Decision Message (DEC) PDP -> PEP.........................25
6.3 Report State Message (RPT) PEP -> PDP.....................26
Security Considerations..........................................26
IANA Considerations..............................................26
Normative References.............................................27
Informative References...........................................27
Acknowledgments..................................................27
Author's Addresses...............................................27
Intellectual Property Statement..................................28
Disclaimer of Validity...........................................29
Copyright Statement..............................................29
1. Introduction
Multimedia Telephony Services (e.g. voice/video calls, SMS/MMS
services, multi-party audio/video conference) based on all-IP
networks poses new challenging requirements for the infrastructures
of Service Providers (SP) in terms of end-to- end Quality of Service
(QoS), dynamical and tailored network resource management,
security/privacy, service availability, service resiliency, etc.
All these issues are supported by the traditional PSTN for the basic
telephony services, but they cannot be effectively and natively
provided by the standard IP networks, which are based on the flat
"best-effort" and connectionless paradigm.
Focusing on the SP network, the presence of heterogeneous multimedia
applications requiring QoS guarantees on the boundary of its network
entails general requirements for:
- flexibility/modularity of the SP architecture, in order to
provide new multimedia services with the least possible impact on
the SP internal infrastructure;
- scalability of the SP network, in order to scale well with the
increasing of service demands from the users through the related
access networks;
- dynamicity of the service provisioning, in order to offer
dynamically (i.e. as long as the end-user needs) a transport
service for the MTS with QoS guarantees (both at Layer 3 and at
Layer 2);
- tailoring of the SP QoS-enabled transport services, in order to
allocate the amount of network resources that exactly fulfil the
end-user requirements in terms of bandwidth, delays, jitter, etc.
This specification aims to define some extensions to the COPS
protocol under the COPS-MAID client type to be used in a signalling
Carrozzo et al. Expires - November 2005 [Page 3]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
independent architecture for the SP Control Plane. This architecture
satisfies the requirements for flexibility and scalability of the
network, as well as dynamicity and tailoring of the related transport
services. This control plane architecture is defined signalling
independent because it is able to uphold different signalling
protocols used by the MTS-enabled terminals (e.g. SIP, H.323, H.248-
Megaco, MGCP, etc.) with a common approach, according to a
"classical" User-Network Interface concept.
2. MAID network architecture
The requirement for end-to-end QoS guarantees for MTS sessions
implies that the SP network must comprise QoS-capable equipment. The
most effective and common choices that currently gather scalability
and manageability are Diffserv [5], MPLS [6] and a mixed MPLS/
Diffserv solution [3], which merges the Control Plane features of
MPLS with the differentiation and scheduling tools provided by
Diffserv.
The Multi-Access Inter-Domain (MAID) SP network derives from this
rationale and it relies on a mixed MPLS/Diffserv architecture (both
Control and Data Planes).
The MAID Data Plane provides the mapping and the forwarding of the IP
flows from the access network into the proper Diffserv PHBs/LSPs
(labels) and vice versa.
The MAID 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.
Focusing on the Control Plane side, the SP network is a collection of
functionalities and components, in support of signalling, security,
billing, inter-working of domains, etc. relying on the coordination
function of an MTS Call Agent (e.g. the H.323 Gatekeeper, or the SIP
Proxy or a softswitch in general). After a successful phase of
subscription and registration of end-users to the SP services, upon
receiving a service request for an MTS call from an end-user, the SP
control plane is triggered to provide:
1. the authorization, authentication and accounting of the end-
user;
2. the call control through a MTS Call Agent;
3. the inter-working with peering domains of the same or different
technologies (e.g. neighbouring TDM domains or other
SIP/H.323 domains);
4. the setup/selection/update/release of the QoS-enabled IP service
in the SP data plane that can accommodate the final MTS call, in
case across a chain of SP domains.
Carrozzo et al. Expires - November 2005 [Page 4]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
The last step, i.e. the selection of a just running QoS-enabled IP
service and/or the set-up of a new one inside the SP network, is the
main QoS-related step and it relies on the action of a Transport
Network Resource Manager (TNRM), also known as Bandwidth Broker (BB).
The TNRM has the main role of managing network resources by means of
proper configurations of the Traffic Control (TC) modules in the
involved QoS-capable IP/MPLS routers, as well as the Layer 2 priority
mechanisms of the involved L2 devices. TC is the set of policing,
filtering, marking, shaping and scheduling procedures available on
the IP routers for QoS enforcement purposes.
The triggers for TNRM actions can be:
- requests for call admission control originated by the MTS Call
Agent and related to the MTS signalling
- some provisioning information (e.g. traffic matrix like)
These two solutions are generally classified as outsourcing and
provisioning approaches. Outsourcing allows a dynamic distribution of
available resources, even if it requires the continuous TNRM
invocation and, thus, it implies scalability issues. On the contrary,
provisioning relies on the pre-allocation of a set of policies (and a
certain amount of resources) by the TNRM to external Policy
Enforcement Points. In this case TNRM acts as a Policy Decision
Point. It would be desirable to adopt a mixed provisioning/
outsourcing scheme, in order to address both the scalability and
resource optimisation issues.
The scalability issues raised by the different MTS architectures
(e.g. H.323, SIP, etc.) interoperating with the single TNRM encourage
the definition of a common syntax for admission control and policy
requests despite of the native MTS signalling protocol (e.g. SIP,
H.323, H.248, etc.) and of the SP internal network architecture (e.g.
Diffserv, MPLS or both). This approach allows shifting the complexity
of the network on a single module, the Signalling Translation
Function (STF), which is related to the MTS Call Agent and, thus, can
be distributed in different network elements.
The main actions provided by STF are:
- to map the QoS semantic of the specific MTS signalling protocol
into a generalized and common semantic for the QoS-enabled IP
service request;
- to provide the inter-working with the native signalling protocol
dynamics (i.e. message flows), depending on the result of the
admission control phase by the TNRM.
Carrozzo et al. Expires - November 2005 [Page 5]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
The STF translation do not extend nor modify the native MTS
signalling, but it simply supports the MTS signalling by providing
the missing correlation between the signalling/media negotiation and
the relative actions in the SP transport network in terms of QoS
configuration and enforcement.
3. The COPS-MAID rationale
This specification focuses on the possibility of integrating
different MTS protocol architectures through the STF module. Since a
per-protocol QoS semantic can be identified from the MTS call
signalling messages, it is possible to derive a minimum set of
information the TNRM must know in order to provide a correct policy
decision and call admission control.
This common semantic is comprised of:
- Traffic origin:
> host which originated the flow;
> Border Router (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, the
QoS-sensible information highlighted above MUST be passed from the
STF to the TNRM via a specific protocol. Different protocols can be
extended for this purpose (e.g. DIAMETER, SIP, etc.). In this
specification some extensions to the COPS protocol are proposed under
the COPS-MAID client type (MAID, Multiple-Access Inter-Domain).
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
Carrozzo et al. Expires - November 2005 [Page 6]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
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.
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" Bandwidth Broker.
In this specification a unified COPS semantic is proposed 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 generalized architecture it is possible to reduce
the complexity of the system, because:
- 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 Bandwidth Broker or TNRM.
The COPS-MAID client type and the related objects are defined in the
following sections.
4. 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.
4.1 Client Type
COPS-MAID is COPS client-type TBD.
Carrozzo et al. Expires - November 2005 [Page 7]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
4.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;
4.3 COPS-MAID Protocol Objects Format
All the objects described in this section must 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. 5.1 for the PEP -> PDP
communication) and in the Client Specific Decision Object (ref. 5.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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 binding requests
sent by the PEP and having the same COPS Handle Object with responses
coming from the PDP (ref. [3]). This mechanism allows a COPS-MAID PEP
to make more than one request for a specific state (identified by the
Handle Object) before receiving a PDP response.
Carrozzo et al. Expires - November 2005 [Page 8]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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 TNRM in order to
perform Authorization operations.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Host IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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 MTS Call Agent 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 TNRM in order to perform flow authorization operations.
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Host IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo et al. Expires - November 2005 [Page 9]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source Host IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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 MTS Call Agent 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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.9 IPv4 Ingress Border Router Interface Object/TrunkID
This object specifies the IPv4 address of the ingress BR 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.
Carrozzo et al. Expires - November 2005 [Page 10]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
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:
- 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.
4.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:
Carrozzo et al. Expires - November 2005 [Page 11]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
- 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.
4.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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.13 Traffic Type Object
Traffic Type Objects are maintained in the form of a list in which
each Traffic Type ID value corresponds to a predefined (either
standardized or client defined) characterization:
Traffic Type ID = value -> characterization.
Carrozzo et al. Expires - November 2005 [Page 12]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
- 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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.
Carrozzo et al. Expires - November 2005 [Page 13]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
Priorities for the flow are 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.[8]).
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 types 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,
Carrozzo et al. Expires - November 2005 [Page 14]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
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.
4.14.1 Profile Characterization for Type 1
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.14.2 Profile Characterization for Type 2
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo et al. Expires - November 2005 [Page 15]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.14.5 Profile Characterization for Type 5
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Rate |
Carrozzo et al. Expires - November 2005 [Page 16]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Probability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Probability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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 these classes has more stringent QoS guarantees than the
previous class.
Carrozzo et al. Expires - November 2005 [Page 17]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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
Carrozzo et al. Expires - November 2005 [Page 18]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
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
- Recovery diversity = 0x0003: SRLG
- Recovery diversity = TBA
4.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;
Carrozzo et al. Expires - November 2005 [Page 19]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
The Label value is set according to the specified Label Type.
4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 are used for increase the readability and are suppressed in
the TempInfo object value.
Carrozzo et al. Expires - November 2005 [Page 20]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
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-D-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.
4.20 Explicit Route object
The contents of an Explicit Route object are a series of variable-
length data items called sub-objects. 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)
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 MPLS-enabled ingress BR
(LER) of the MPLS/Diffserv SP network that an MPLS signalling session
(e.g. via RSVP-TE protocol) must be initiated 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo et al. Expires - November 2005 [Page 21]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
4.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
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.
4.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.
4.20.1.2 Sub-object 1: IPv6 prefix
0 7 15 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carrozzo et al. Expires - November 2005 [Page 22]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
|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.
4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.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 = ....
5. COPS-MAID Client Specific Information Object
Carrozzo et al. Expires - November 2005 [Page 23]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
5.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:
<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)
Carrozzo et al. Expires - November 2005 [Page 24]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
[<QoSDesc(s)>] (old)
[<QoSPrms(s)>] (new)
[<QoSPrms(s)>] (old)
[<Recov(s)>] (new)
[<Recov(s)>] (old)
[<TempInfo(s)>] (new)
[<TempInfo(s)>] (old)
5.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
6. Message content
6.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>]
6.2 Decision Message (DEC) PDP -> PEP
<Decision Message> ::= <Common Header>
Carrozzo et al. Expires - November 2005 [Page 25]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
<Client Handle>
<Decision> | <Error>
[<Integrity>]
<Decision>::= <Context = Resource-Allocation request>
<Decision: Flags>
<Decision: COPS-MAID decision data>
6.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].
IANA Considerations
Within this document a new COPS Client Type (COPS-MAID) is defined
and it needs to be assigned in compliancy with the IANA assignments
for the COPS protocol parameters:
http://www.iana.org/assignments/cops-parameters
A Client-type values within the range 0x0001-0x3FFF (Specification
Required) could apply to this specification, since the behavior and
applicability of the COPS-MAID extensions are hereby described.
The other extensions described in this document are in the form of
TLV sub-objects carried by the COPS-MAID Client Specific Information
Object (ref. 5.1 for the PEP -> PDP communication) and in the Client
Specific Decision Object (ref. 5.2 for the PDP -> PEP direction).
Carrozzo et al. Expires - November 2005 [Page 26]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
The Type values assigned by authors for each of them from sec. 4.4 to
sec. 4.21 are those suggested for IANA assignment.
Normative 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]Durham D., Ed., "The COPS (Common Open Policy Service) Protocol",
RFC 2748, January 2000.
[4] Herzdog S., Ed., "COPS Usage for RSVP", RFC 2749, January 2000.
Informative References
[5]Blake S. et al., "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[6] Rosen E. et al., "Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[7] Le Faucheur F., Ed., "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May 2002.
[8] Black D. et al., "Per Hop Behavior Identification Code", RFC
3140, June 2001.
Acknowledgments
This work has been supported by the European Commission through the
Integrated Project "Multimedia Networking (MediaNet)" - IST-Project
no. FP6-507452.
Author's Addresses
Gino Carrozzo
Divisione Informatica e Telecomunicazioni - Consorzio Pisa Ricerche
C.so Italia, 116
56100 Pisa, ITALY
Carrozzo et al. Expires - November 2005 [Page 27]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
Email: g.carrozzo@cpr.it
Nicola Ciulli
Divisione Informatica e Telecomunicazioni - Consorzio Pisa Ricerche
C.so Italia, 116
56100 Pisa, ITALY
Email: n.ciulli@cpr.it
Gianluca Insolvibile
Divisione Informatica e Telecomunicazioni - Consorzio Pisa Ricerche
C.so Italia, 116
56100 Pisa, ITALY
Email: g.insolvibile@cpr.it
Giacomo Sergio
Divisione Informatica e Telecomunicazioni - Consorzio Pisa Ricerche
C.so Italia, 116
56100 Pisa, ITALY
Email: g.sergio@cpr.it
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.
Information on the IETF's procedures with respect to rights in IETF
Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Carrozzo et al. Expires - November 2005 [Page 28]
Internet Draft draft-carrozzo-aaa-cops-maid-00.txt May 2005
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Carrozzo et al. Expires - November 2005 [Page 29]
