Internet Engineering Task Force F. Huang, Ed.
Internet-Draft T. Taylor
Intended status: Standards Track Huawei Technologies
Expires: January 14, 2011 G. Zorn
Network Zen
H. Tschofenig
Nokia Siemens Networks
July 13, 2010
Diameter Application To Transfer PCN Data From Edge Nodes To a
Centralized Decision Point
draft-huang-dime-pcn-collection-03
Abstract
Pre-congestion notification (PCN) is a technique for maintaining QoS
for inelastic flows in a DIFFServ domain. The PCN architecture
requires that egress nodes send regular reports of PCN-defined
measurements to a decision point. It requires further that the
decision point occasionally be able to request certain measurements
from ingress nodes. The decision point can be located in different
places in the network. This memo defines a Diameter application to
support communications between the ingress and egress nodes and a
Diameter server acting as a PCN decision point.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 14, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Huang, et al. Expires January 14, 2011 [Page 1]
Internet-Draft PCN Data Collection July 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Huang, et al. Expires January 14, 2011 [Page 2]
Internet-Draft PCN Data Collection July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Egress Node Behaviour . . . . . . . . . . . . . . . . . . 5
3.2. Decision Point Behaviour . . . . . . . . . . . . . . . . . 5
3.3. Ingress Node Behaviour . . . . . . . . . . . . . . . . . . 6
4. Diameter PCN Data Collection Application . . . . . . . . . . . 6
4.1. Advertising Application Support . . . . . . . . . . . . . 6
4.2. Session Management . . . . . . . . . . . . . . . . . . . . 6
4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 7
4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 8
4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 8
4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 9
4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 9
4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 10
4.4.2. PCN-Ingress-Node-Address AVP . . . . . . . . . . . . . 10
4.4.3. PCN-Egress-Node-Address AVP . . . . . . . . . . . . . 10
4.4.4. Framed-IP-Address AVP . . . . . . . . . . . . . . . . 10
4.4.5. Framed-IPv6-prefix AVP . . . . . . . . . . . . . . . . 10
4.4.6. VLAN-ID-Range AVP . . . . . . . . . . . . . . . . . . 11
4.4.7. Aggregate-PCN-Egress-Data AVP . . . . . . . . . . . . 11
4.4.8. NM-Rate AVP . . . . . . . . . . . . . . . . . . . . . 11
4.4.9. ETM-Rate AVP . . . . . . . . . . . . . . . . . . . . . 11
4.4.10. ThM-Rate AVP . . . . . . . . . . . . . . . . . . . . . 11
4.4.11. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 11
4.4.12. Classifier AVP . . . . . . . . . . . . . . . . . . . . 12
4.4.13. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 12
4.4.14. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 12
4.5. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Diameter Application Identifier . . . . . . . . . . . . . 13
5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 13
5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 14
6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Appendix A. Related Work in ITU-T . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Huang, et al. Expires January 14, 2011 [Page 3]
Internet-Draft PCN Data Collection July 2010
1. Introduction
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain
[RFC2475] in a simple, scalable and robust fashion. Admission
control allows decisions on whether to admit or reject a new flow
request, and (in abnormal circumstances, such as router failure) to
provide flow termination of already admitted flows. These two
mechanisms together aim to protect the QoS properties of previously
admitted flows. To achieve this, the overall rate of the PCN traffic
is metered on every link in the PCN domain, and PCN packets are
appropriately marked when certain configured rates are exceeded.
These configured rates are below the rate of the link thus providing
notification before any congestion occurs ("pre-congestion
notification"). The level of marking allows decisions to be made
about whether to admit or terminate. A more detailed description of
the architecture can be found in [RFC5559].
Marking statistics are gathered by egress nodes on a per-ingress-
egress aggregate basis. If multipath routing is in use, egress nodes
may also send a list of individual flows along with the marking
statistics, if these flows have experienced an elevated level of pre-
congestion.
The reported statistics are processed to determine whether new flows
can be admitted to the aggregate over the next measurement interval
and whether some flows should be terminated to protect QoS for the
remainder. (Flow termination is expected to be relatively
infrequent, typically a result of network failure.) The admission
state is based on a congestion level estimate (CLE), which the
decision node derives from the statistics that the egress node passes
to the decision point. The decision to terminate flows is made on
the basis of a different criterion, also derived from those
statistics. For further details see [I-D.SM-edge-behaviour] and
[I-D.CL-edge-behaviour].
2. Requirements Language
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 [RFC2119].
3. Procedures
The following subsections discuss the processing requirements placed
upon the various participating Diameter nodes by the PCN Data
Huang, et al. Expires January 14, 2011 [Page 4]
Internet-Draft PCN Data Collection July 2010
Collection application.
3.1. Egress Node Behaviour
The egress node measures the traffic from a particular ingress node,
and calculates either two or three flow rates (octets per second) at
the ingress-egress-aggregate level, based on the PCN markings of the
packets it receives and the edge node behaviour that has been
deployed. The three rates are the PCN-unmarked rate (NM-Rate), the
PCN-threshold-marked rate (ThM-Rate), and the PCN-excess-traffic-
marked rate (ETM-Rate). The ThM-Rate is collected for the CL edge
node behaviour [I-D.CL-edge-behaviour], but not for the SM edge node
behaviour [I-D.SM-edge-behaviour]. The egress node calculates these
rates and reports them to the decision point every 100 to 500 ms.
The CL and SM edge node behaviour specifications also provide an
option for the egress node to calculate a congestion level estimate
(CLE), equal to the ratio of PCN-marked to total PCN traffic received
in the interval. The egress node reports the calculated CLE to the
decision point along with the basic traffic rates.
The CL and SM edge node behaviour specifications provide a further
option for report suppression when the calculated CLE is below a
reporting threshold for two or more successive reporting periods. It
is RECOMMENDED that the operator configure egress nodes to activate
the CLE reporting and report suppression options, to minimize the
reporting traffic volume in the network and the the processing load
at the decision point.
For the CL mode only, when multipath routing is in effect, the egress
node may be configured to collect identifiers of flows that
experienced PCN-excess-traffic-marking during the measurement
interval along with the calculated traffic rates.
The egress node MUST use a Congestion Report Request (CRR) command to
send the calculated rates and the flow identifiers, when applicable,
to the decision node. The Event-Timestamp AVP MUST be present within
the CRR, and MUST indicate the ending time of the latest measurement
period represented by the information within the message. At least
one instance of the Aggregate-PCN-Egress-Data AVP MUST be present.
Multiple instances of this AVP MAY be present, but each instance MUST
report on a different ingress-egress-aggregate.
3.2. Decision Point Behaviour
If the decision point receives an Congestion-Report-Request (CRR)
identified as belonging to the PCN Data Collection application, it
MUST acknowledge the message with a Congestion-Report-Answer (CRA).
Huang, et al. Expires January 14, 2011 [Page 5]
Internet-Draft PCN Data Collection July 2010
The decision point usage of the information provided by PCN-
Congestion-Info and PCN-Excess- Flow-Info AVPs is described in the
applicable edge behavior specification ([I-D.SM-edge-behaviour] or
[I-D.CL-edge-behaviour].
The decision point MAY send a Measurement-Poll-Request (MPR) to the
ingress node for a specific ingress-egress-aggregate for which flow
termination appears to be required. The decision point will make the
decision about sending the MPR depending on the content of the CRR
relating to the ingress-egress- aggregate concerned. The decision
point SHOULD copy the Event-Timestamp AVP it received in the CRR to
the MPR.
If the decision point receives a successful Measurement-Poll-Answer
message, it uses the information contained in the PCN-Sent-Info AVP
to determine how much traffic to terminate, as described in
[I-D.SM-edge-behaviour] or [I-D.CL-edge-behaviour].
3.3. Ingress Node Behaviour
When an ingress node receives an MPR, it MUST generate a Measurement-
Poll-Answer message containing an instance of the PCN-Sent-Info AVP.
The I-E-Aggregate-Id within the PCN-Sent-Info AVP MUST be the same as
received in the MPR, and the I-E-Aggregate-Sent-Rate MUST be a rate
measured for that aggregate. If Event-Timestamp is present in the
MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based
SHOULD be that for a period after the time given by Event-Timestamp.
In any case, Event- Timestamp MUST be present in the MPA, and if it
is, MUST give the end-time of the measurement period upon which I-E-
Aggregate-Sent-Rate is based.
4. Diameter PCN Data Collection Application
4.1. Advertising Application Support
Clients, servers, and proxies supporting the PCN Data Collection
application MUST advertise support by including the value <AID> in
the Auth-Application-Id of Congestion-Report-Request (CRR),
Congestion-Report-Answer (CRA), Measurement-Poll-Request (MPR), and
Measurement-Poll-Answer (MPA) messages.
4.2. Session Management
Diameter sessions for this application are implicitly terminated. An
implicitly terminated session is one for which the server does not
maintain session state information. The client does not need to send
any re- authorization or session termination requests to the server.
Huang, et al. Expires January 14, 2011 [Page 6]
Internet-Draft PCN Data Collection July 2010
The Diameter base protocol includes the Auth-Session-State AVP as the
mechanism for the implementation of implicitly terminated sessions.
The client (server) SHALL include in its requests (responses) the
Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as
described in RFC 3588 [RFC3588]. As a consequence, the server does
not maintain any state information about this session and the client
does not need to send any session termination request. Neither the
Authorization-Lifetime AVP nor the Session-Timeout AVP SHALL be
present in requests or responses.
4.3. Commands
The PCN Data Collection application defines four new commands,
Congestion-Report-Request(CRR), Congestion-Report-Answer(CRA),
Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA).
4.3.1. Congestion-Report-Request (CRR) Command
The egress node sends the Congestion-Report-Request (CRR) command,
indicated by the Command-Code field set to <CC1> and the Command
Flags' 'R' bit set, to report PCN marking statistics and possibly
individual flow identifiers. Multiple reports for different ingress-
egress-aggregates MAY be included in the same message, as described
in Section 3.1.
Message format:
<CRR> ::= < Diameter Header: CC1, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
* ( Aggregate-PCN-Egress-Data )
( Event-Timestamp ]
[ Destination-Host ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
At least one instance of the Aggregate-PCN-Egress-Data AVP MUST be
present. The value of the Session-Id AVP MUST be unique and SHOULD
be set according to the recommendations in Section 8.8 of RFC 3588
[RFC3588].
Huang, et al. Expires January 14, 2011 [Page 7]
Internet-Draft PCN Data Collection July 2010
4.3.2. Congestion-Report-Answer (CRA) Command
The decision point uses the Congestion-Report-Answer (CRA) command,
indicated by the Command-Code field set to <CC1> and the Command
Flags' 'R' bit cleared, to acknowledge a Congestion-Report-Request
command sent by an egress node. The Congestion-Report-Answer command
contains the same Session-Id as the corresponding request. The
Event-Timestamp AVP MUST be present and MUST contain the value
received in the CRR that is being acknowledged.
Message format:
<CRA> ::= < Diameter Header: CC1, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
( Event-Timestamp )
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Proxy-Info ]
* [ AVP ]
4.3.3. Measurement-Poll-Request (MPR) Command
The decision point sends the Measurement-Poll-Request (MPR) command,
indicated by the Command-Code field set to <CC2> and the Command
Flags' 'R' bit set, to request that an ingress node report the rate
at which PCN- marked traffic has been forwarded to a given ingress-
egress aggregate, measured over a time period constrained as
described in Section 3.3. The value of the Session-Id AVP MUST be
unique and SHOULD be set according to the recommendations in Section
8.8 of RFC 3588 [RFC3588]. The I-E-Aggregate-Id AVP MUST be present.
The Event-Timestamp AVP SHOULD be present.
Message format:
Huang, et al. Expires January 14, 2011 [Page 8]
Internet-Draft PCN Data Collection July 2010
<MPR> ::= < Diameter Header: CC2, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ I-E-Aggregate-Id }
[ Destination-Host ]
[ Event-Timestamp ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
4.3.4. Measurement-Poll-Answer (MPA) Command
The ingress node sends the Measurement-Poll-Answer (MPA) command,
indicated by the Command-Code field set to <CC2> and the Command
Flags' 'R' bit cleared, in response to an MPR sent by the decision
point. The Session-Id MUST be copied from the MPR to which the MPA
is responding. The PCN-Sent-Info and Event-Timestamp AVPs MUST be
present.
Message format:
<MPA> ::= < Diameter Header: CC2, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ PCN-Sent-Info }
( Event-Timestamp )
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Proxy-Info ]
* [ AVP ]
4.4. Attribute Value Pairs (AVPs)
This section describes the AVPs specific to the PCN Data Collection
application. The 'M' bit MUST be set and the 'V' bit MUST NOT be set
for all of these AVPs when used in the PCN Data Collection
application.
Huang, et al. Expires January 14, 2011 [Page 9]
Internet-Draft PCN Data Collection July 2010
4.4.1. I-E-Aggregate-Id AVP
The I-E-Aggregate-Id AVP (AVP code <AVP1>) is of type Grouped and
identifies a specific aggregate.
The I-E-Aggregate-Id AVP has the following format:
EDITOR'S NOTE: may need to add something that works for MPLS.
I-E-Aggregate-Id ::= < AVP Header: AVP1 >
[ PCN-Ingress-Node-Address ]
[ PCN-Egress-Node-Address ]
[ VLAN-ID-Range ]
* [ AVP ]
4.4.2. PCN-Ingress-Node-Address AVP
The PCN-Ingress-Node-Address AVP (AVP code <AVP2>) is of type Grouped
and contains the address of a PCN-Ingress-Node.
The PCN-Ingress-Node-Address AVP has the following format:
PCN-Ingress-Node-Address ::= < AVP Header: AVP2 >
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
4.4.3. PCN-Egress-Node-Address AVP
The PCN-Egress-Node-Address AVP (AVP code <AVP3>) is of type Grouped
and contains the address of a PCN-Egress-Node.
The PCN-Egress-Node-Address AVP has the following format:
PCN-Egress-Node-Address ::= < AVP Header: AVP3 >
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
4.4.4. Framed-IP-Address AVP
The Framed-IP-Address AVP is defined in the NASREQ application (RFC
4005 [RFC4005]).
4.4.5. Framed-IPv6-prefix AVP
The Framed-IPv6-prefix AVP is defined in the NASREQ application (RFC
4005 [RFC4005]).
Huang, et al. Expires January 14, 2011 [Page 10]
Internet-Draft PCN Data Collection July 2010
4.4.6. VLAN-ID-Range AVP
The VLAN-ID-Range AVP, defined in ietf-dime-qos-attributes [I-D.ietf-
dime-qos-attributes], is of type Grouped and specifies the VLAN range
to match.
4.4.7. Aggregate-PCN-Egress-Data AVP
The PCN-Congestion-Info AVP (AVP code <AVP4>) is of type Grouped. It
identifies an ingress-egress aggregate, reports the current value of
the PCN-unmarked, PCN-excess-traffic-marked, and optionally, PCN-
threshold- marked traffic rates and the CLE, and MAY identify zero or
more flows experiencing excess-traffic-marking.
The PCN-Congestion-Info AVP has the following format:
Aggregate-PCN-Egress-Data ::= < AVP Header: AVP4 >
{ I-E-Aggregate-Id }
{ NM-Rate }
{ ETM-Rate }
[ ThM-Rate ]
[ CLE-Value ]
* [ Classifier ]
* [ AVP ]
4.4.8. NM-Rate AVP
The NM-Rate AVP (AVP code <AVP5>) is of type Unsigned32. It gives
the calculated rate of receipt of PCN-unmarked traffic in octets per
second for a given ingress-egress-aggregate.
4.4.9. ETM-Rate AVP
The ETM-Rate AVP (AVP code <AVP6>) is of type Unsigned32. It gives
the calculated rate of receipt of excess-traffic-marked traffic in
octets per second for a given ingress-egress-aggregate.
4.4.10. ThM-Rate AVP
The ThM-Rate AVP (AVP code <AVP7>) is of type Unsigned32. It gives
the calculated rate of receipt of threshold-marked traffic in octets
per second for a given ingress-egress-aggregate.
4.4.11. CLE-Value AVP
The CLE-Value AVP (AVP code <AVP8>) is of type Unsigned32. It gives
the calculated ratio of traffic rates of PCN-marked traffic to total
PCN traffic received at the egress node, multiplied by 1000 and
Huang, et al. Expires January 14, 2011 [Page 11]
Internet-Draft PCN Data Collection July 2010
truncated, for a given ingress-egress-aggregate. By construction,
the value of the CLE-Value AVP ranges from 0 to 1000.
4.4.12. Classifier AVP
The Classifier AVP (AVP Code 511) is a grouped AVP that consists of a
set of attributes that specify how to match a packet. The Classifier
AVP is defined in [RFC5777]. In the present specification its
purpose is to identify a flow that is experiencing excess-traffic-
marking.
4.4.13. PCN-Sent-Info AVP
The PCN-Sent-Info AVP (AVP code <AVP9>) is of type Grouped. It
provides the estimated rate of flow of PCN traffic in octets per
second that the ingress node has admitted to a given ingress-egress-
aggregate.
The PCN-Sent-Info AVP has the following format:
PCN-Sent-Info ::= < AVP Header: AVP9 >
{ I-E-Aggregate-Id }
{ I-E-Aggregate-Sent-Rate }
* [ AVP ]
4.4.14. I-E-Aggregate-Sent-Rate AVP
The I-E-Aggregate-Sent-Rate AVP (AVP code <AVP10>) is of type
Unsigned32. It gives the estimated rate of flow of PCN traffic in
octets per second that the ingress node forwarded to the identified
ingress-egress aggregate, calculated for the measurement period
ending at the time given by the Event-Timestamp AVP.
4.5. AVP Occurrence Tables
The following table presents the AVPs defined in this document and
their occurrences in Diameter messages. Note that AVPs that can only
be present within a Grouped AVP are not represented in this table.
The table uses the following symbols:
0: The AVP MUST NOT be present in the message.
1: One instance of the AVP MUST be present in the message.
Huang, et al. Expires January 14, 2011 [Page 12]
Internet-Draft PCN Data Collection July 2010
1+: One or more instances of the AVP MUST be present in the message.
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
AVP Name | CRR | CRA | MPR | MPA |
-------------------------------|-----+-----+-----+-----+
Aggregate-PCN-Egress-Data | 1+ | 0 | 0 | 0 |
PCN-Sent-Info | 0 | 0 | 0 | 1 |
I-E-Aggregate-Id | (*) | 0 | 1 | (*) |
+-----+-----+-----+-----+
(*): Note that the I-E-Aggregate-Id AVP appears alone in the MPR
command and is contained within the Aggregate-PCN-Egress-Data grouped
AVP (CRR command) and the PCN-Sent-Info grouped AVP (MPA command).
5. IANA Considerations
Upon publication of this memo as an RFC, IANA is requested to assign
values as described in the following sections.
5.1. Diameter Application Identifier
An application identifier for Diameter PCN Data Collection (<AID>,
Section 4.1) must be assigned according to the policy specified in
Section 11.3 of [RFC3588].
5.2. Diameter Command Codes
Codes must be assigned for the following commands according to the
policy specified in [RFC3588], Section 11.2.1:
o Congestion-Report-Request (CRR) and Congestion-Report-Answer (CRA)
(<CC1>, Section 4.3.1 and Section 4.3.2).
o Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA)
(<CC4>, Section 4.3.3 and Section 4.3.4).
5.3. Attribute-Value Pairs
Codes must be assigned for the following AVPs using the policy
specified in [RFC3588], Section 11.1.1:
Huang, et al. Expires January 14, 2011 [Page 13]
Internet-Draft PCN Data Collection July 2010
o I-E-Aggregate-Id (<AVP1>, Section 4.4.1)
o PCN-Ingress-Node-Address (<AVP2>, Section 4.4.2)
o PCN-Egress-Node-Address (<AVP3>, Section 4.4.3)
o Aggregate-PCN-Egress-Data (<AVP4>, Section 4.4.7)
o NM-Rate (<AVP5>, Section 4.4.8)
o ETM-Rate (<AVP6>, Section 4.4.9)
o ThM-Rate (<AVP7>, Section 4.4.10)
o CLE-Value (<AVP8>, Section 4.4.11)
o PCN-Sent-Info (<AVP9>, Section 4.4.13)
o I-E-Aggregate-Sent-Rate (<AVP10>, Section 4.4.14).
6. Security Considerations
The following sections discuss the security threats against the
Diameter PCN Data Collection application and describe some
countermeasures.
6.1. Traffic Security
Application traffic MUST be secured as specified in RFC 3588
[RFC3588] (i.e., through the use of (preferably) TLS or IPsec). In
the absence of appropriate protection, all manner (including man-in-
the-middle) of attacks are possible, potentially resulting in the
inappropriate termination and non-admittance of flows.
6.2. Device Security
Compromise of an ingress node by an attacker could result in the
inappropriate refusal of admittance to valid flows, while the
compromise of an egress node could allow the termination of valid
flows.
Compromise of the decision point could result in both denial of
admission to new flows and termination of existing flows, enabling an
attacker to essentially control PCN traffic on the affected network.
7. References
Huang, et al. Expires January 14, 2011 [Page 14]
Internet-Draft PCN Data Collection July 2010
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
and A. Lior, "Traffic Classification and Quality of
Service (QoS) Attributes for Diameter", RFC 5777,
February 2010.
7.2. Informative References
[I-D.CL-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Controlled
Load (CL) Mode of Operation (Work In progress)",
June 2010.
[I-D.SM-edge-behaviour]
Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Single
Marking (SM) Mode of Operation (Work in progress)",
June 2010.
[Q.3303.3]
ITU-T, "Resource control protocol No. 3 -- Protocols at
the Rw interface between a policy decision physical entity
(PD-PE) and a policy enforcement physical entity (PE-PE):
Diameter", ITU-T Recommendation Q.3303.3, May 2008.
<http://www.itu.int/rec/T-REC-Q.3303.3>
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface
Application", RFC 5431, March 2009.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
Huang, et al. Expires January 14, 2011 [Page 15]
Internet-Draft PCN Data Collection July 2010
Appendix A. Appendix A. Related Work in ITU-T
The ITU-T is doing work to exploit the PCN technology in an
environment where the decisions are made by a central policy decision
point (decision point) [Q.3303.3], which needs the information
generated by PCN marking to support per-flow decisions on admission
and termination. This memo defines a Diameter application to
transfer the information from edge nodes to the decision point.
Egress node reports are sent by the egress node acting as client to
the decision point acting as server. Data generated at the ingress
node are needed only when flow termination is required. They are
requested by the decision point acting as client and sent in
responses by the ingress node acting as server. The decision point
thus acts both as client and as server in the same application. The
Rw application [RFC5431] provides a precedent for such an
application.
The PCN Data Collection application is related to existing ITU-T
applications as follows:
o The Rs application allows application-level functions to request
flow admission for individual application flows.
o The Rw application provides the control linkage between a Policy
Decision Point and an ingress router, to pass down decisions on
flow admission following either the push or the pull model. The
Rw application also passes flow termination decisions.
As can be seen from this brief description, the PCN Data Collection
application defined in this memo is complementary to the Rw
application. Within the strict terms of the ITU-T architecture, it
is a realization of a different interface, the Rc interface.
However, the PCN Data Collection application is intended for use in
any of a number of architectures based on a centralized policy
decision element.
Authors' Addresses
Fortune Huang (editor)
Huawei Technologies
Section F, Huawei
Industrial Base
Bantian Longgang, Shenzhen 518129
P.R. China
Email: fqhuang@huawei.com
Huang, et al. Expires January 14, 2011 [Page 16]
Internet-Draft PCN Data Collection July 2010
Tom Taylor
Huawei Technologies
Ottawa, Ontario
Canada
Email: tom111.taylor@bell.net
Glen Zorn
Network Zen
1310 East Thomas Street
#306
Seattle,, Washington 98102
USA
Phone: +1 (206) 377-9035
Email: gwz@net-zen.net
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Huang, et al. Expires January 14, 2011 [Page 17]