A Framework for Session Initiation Protocol (SIP) Session Policies
RFC 6794
| Document | Type | RFC - Proposed Standard (December 2012) | |
|---|---|---|---|
| Authors | Gonzalo Camarillo , Jonathan Rosenberg , Volker Hilt | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Robert Sparks | |
| Send notices to | (None) |
RFC 6794
Internet Engineering Task Force (IETF) B. Claise
Request for Comments: 7119 Cisco Systems, Inc.
Category: Standards Track A. Kobayashi
ISSN: 2070-1721 NTT
B. Trammell
ETH Zurich
February 2014
Operation of the IP Flow Information Export (IPFIX) Protocol
on IPFIX Mediators
Abstract
This document specifies the operation of the IP Flow Information
Export (IPFIX) protocol specific to IPFIX Mediators, including
Template and Observation Point management, timing considerations, and
other Mediator-specific concerns.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7119.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Claise, et al. Standards Track [Page 1]
RFC 7119 IPFIX MED-PROTO February 2014
Table of Contents
1. Introduction ....................................................2
1.1. IPFIX Documents Overview ...................................3
1.2. IPFIX Mediator Documents Overview ..........................4
1.3. Relationship with the IPFIX and PSAMP Protocols ............5
2. Terminology .....................................................5
3. Handling IPFIX Message Headers ..................................8
4. Template Management ............................................10
4.1. Passing Unmodified Templates through an IPFIX Mediator ....11
4.1.1. Template Mapping and Information Element Ordering ..15
4.2. Creating New Templates at an IPFIX Mediator ...............17
4.3. Handling Unknown Information Elements .....................17
5. Preserving Original Observation Point Information ..............17
5.1. originalExporterIPv4Address Information Element ...........20
5.2. originalExporterIPv6Address Information Element ...........20
6. Managing Observation Domain IDs ................................20
6.1. originalObservationDomainId Information Element ...........21
7. Timing Considerations ..........................................21
8. Transport Considerations .......................................23
9. Collecting Process Considerations ..............................23
10. Specific Reporting Requirements ...............................23
10.1. Intermediate Process Reliability Statistics
Options Template .........................................24
10.2. Flow Key Options Template ................................26
10.3. intermediateProcessId Information Element ................26
10.4. ignoredDataRecordTotalCount Information Element ..........27
11. Operations and Management Considerations ......................27
12. Security Considerations .......................................28
13. IANA Considerations ...........................................28
14. Acknowledgments ...............................................29
15. References ....................................................29
15.1. Normative References .....................................29
15.2. Informative References ...................................30
1. Introduction
The IPFIX architectural components in [RFC5470] consist of IPFIX
Devices and IPFIX Collectors communicating using the IPFIX protocol
[RFC7011], which specifies how to export IP Flow information. This
protocol is designed to export information about IP traffic Flows and
related measurement data, where a Flow is defined by a set of key
attributes (e.g., source and destination IP address, source and
destination port, etc.).
However, thanks to its Template mechanism, the IPFIX protocol can
export any type of information, as long as the relevant Information
Element is specified in the IPFIX Information Model [RFC7012],
Claise, et al. Standards Track [Page 2]
RFC 7119 IPFIX MED-PROTO February 2014
registered with IANA, or specified as an enterprise-specific
Information Element. The IPFIX protocol [RFC7011] was not originally
written with IPFIX Mediators in mind. Therefore, the IPFIX protocol
must be adapted for Intermediate Processes, as defined in the IPFIX
Mediation Reference Model as specified in Figure A of [RFC6183],
which is based on the IPFIX Mediation Problem Statement [RFC5982].
This document specifies the IP Flow Information Export (IPFIX)
protocol in the context of the implementation and deployment of IPFIX
Mediators. The use of the IPFIX protocol within an IPFIX Mediator --
a device that contains both a Collecting Process and an Exporting
Process -- has an impact on the technical details of the usage of the
protocol. An overview of the technical problem is covered in
Section 6 of [RFC5982]: loss of original Exporter information, loss
of base time information, transport sessions management, loss of
Options Template Information, Template Id management, considerations
for network topology, IPFIX mediation interpretation, and
considerations for aggregation.
The specifications in this document are based on the IPFIX protocol
specifications [RFC7011], but they are adapted according to the IPFIX
Mediation Framework [RFC6183].
1.1. IPFIX Documents Overview
The IPFIX protocol [RFC7011] provides network administrators with
access to IP Flow information.
The architecture for the export of measured IP Flow information out
of an IPFIX Exporting Process to a Collecting Process is defined in
the IPFIX Architecture [RFC5470], per the requirements defined in the
IPFIX Requirements document, [RFC3917].
The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and
Templates are carried via a congestion-aware transport protocol from
IPFIX Exporting Processes to IPFIX Collecting Processes.
IPFIX has a formal description of IPFIX Information Elements, their
names, types, and additional semantic information, as specified in
the IPFIX Information Model [RFC7012]. The IPFIX Information Element
registry [IANA-IPFIX] is maintained by IANA. New Information Element
definitions can be added to this registry subject to an Expert Review
[RFC5226], with additional process considerations described in
[RFC7013]; that document also provides guidelines for authors and
reviewers of new Information Element definitions. The inline export
of the Information Element type information is specified in
[RFC5610].
Claise, et al. Standards Track [Page 3]
RFC 7119 IPFIX MED-PROTO February 2014
The IPFIX Applicability Statement [RFC5472] describes what type of
applications can use the IPFIX protocol and how they can use the
information provided. It furthermore shows how the IPFIX framework
relates to other architectures and frameworks.
1.2. IPFIX Mediator Documents Overview
"IP Flow Information Export (IPFIX) Mediation: Problem Statement"
[RFC5982] provides an overview of the applicability of IPFIX
Mediators and defines requirements for IPFIX Mediators in general
terms. This document is of use largely to define the problems to be
solved through the deployment of IPFIX Mediators and to provide scope
to the role of IPFIX Mediators within an IPFIX collection
infrastructure.
"IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183],
which details the IPFIX Mediation reference model and the components
of an IPFIX Mediator, provides more architectural details of the
arrangement of Intermediate Processes within an IPFIX Mediator.
Documents specifying the operations of specific Intermediate
Processes cover the operation of these Processes within the IPFIX
Mediator framework and comply with the specifications given in this
document; additionally, they may specify the operation of the process
independently, outside the context of an IPFIX Mediator, when this is
appropriate. The details of specific Intermediate Processes, when
they have additional export specifications (e.g., metadata about the
intermediate processing conveyed through IPFIX Options Templates),
are each addressed in their own document. As of today, these
documents are:
1. "IP Flow Anonymization Support&hint the order of the alternative URIs as indicating a preference as
to which URI to use. The topmost URI in the list might be more
preferred by the domain of the proxy for use to obtain the policy.
After receiving policies from the policy server, the UAC decides
whether or not it wants to accept these policies. If the UAC accepts
these policies, the UAC MUST apply them to the current request and
re-send the updated request. If no changes are required by policies
or no policies have been received, the request can be re-sent without
any policy-induced changes. If the UAC decides that the list of
policy servers or the received session policies are unacceptable,
then the UAC MUST NOT re-send the request.
To protect the integrity of the policy server URI in a Policy-Contact
header field, the UAC SHOULD use a secured transport protocol such as
Transport Layer Security (TLS) [RFC5246] between UAC and proxy.
The UAC MUST insert a Policy-ID header field into requests for which
it has contacted a policy server and accepted the policies received.
The Policy-ID header field is a new header field that is defined in
this specification. The UA MUST create a Policy-ID header field
value for each policy server it has contacted during the preparation
of the request. A Policy-ID header field value contains two pieces
of information: the policy server URI and an optional token. The
policy server URI is the URI the UA has used to contact the policy
server. The token is an opaque string the UAC can receive from the
policy server. A token can, for example, be contained in the policy
document [RFC6796]. If the UAC has received a token from the policy
server, the UAC MUST include the token in the Policy-ID header field.
The format of the Policy-ID header field is defined in Section 4.4.5.
The main purpose of the Policy-ID header field is to enable a proxy
to determine if the UAC already knows a URI of the local policy
server. If the policy server URI is not yet known to the UAC, the
proxy can convey this URI to the UAC by rejecting the request with a
488 (Not Acceptable Here) response.
In some cases, a request can traverse multiple domains with a
session-policy server. Each of these domains can return a 488 (Not
Acceptable Here) response containing a policy server URI. A UAC
contacts a policy server after receiving a 488 (Not Acceptable Here)
response from a domain and before re-sending the request. This
creates an implicit order between the policy servers in multiple
domains. That is, a UAC contacts the first policy server, re-sends
the modified request, contacts the second policy server, re-sends the
modified request, and so on. This way, session policies are always
Hilt, et al. Standards Track [Page 16]
RFC 6794 Session Policy Framework December 2012
applied to a request in the order in which the request traverses
through the domains. The UAC MUST NOT change this implicit order
among policy servers.
A UAC frequently needs to contact the policy server in the local
domain before setting up a session. To avoid the retransmission of
the local policy server URI in a 488 (Not Acceptable Here) response
for each new request, a UA SHOULD maintain a cache that contains the
URI of the policy server in the local domain (see Section 4.4.4).
The UAC SHOULD use the cached policy server URI to contact the local
policy server before sending a request that initiates the offer/
answer exchange for a new session (e.g., an INVITE request). The UAC
SHOULD NOT cache a policy server URI that is in a different domain
than the UAC, even if it is the first policy server URI returned.
The first policy server URI returned can be from another domain if
the local domain does not have a policy server. Note that UACs
perform exact domain comparisons. That is, foo.example.com and
example.com are not considered equivalent.
UAs can renegotiate the session description during a session by
initiating a subsequent offer/answer exchange, e.g., in an INVITE,
UPDATE, or PRACK request. When creating such a mid-dialog request, a
UA SHOULD contact all policy servers to which it has established a
policy channel during the initial offer/answer exchange (see
Section 4.5) before sending the request. This avoids the
retransmission of all policy server URIs in 488 (Not Acceptable Here)
responses for mid-dialog requests.
4.4.2. Proxy Behavior
A proxy provides rendezvous functionalities for UAs and policy
server. This is achieved by conveying the URI of a policy server to
the UAC or the UAS (or both) when processing INVITE, UPDATE, or PRACK
requests (or any other request that can initiate an offer/answer
exchange).
If an offer/answer exchange initiating request contains a Supported
header field with the option tag "policy", the proxy MAY reject the
request with a 488 (Not Acceptable Here) response to provide the
local policy server URI to the UAC. Before rejecting a request, the
proxy MUST verify that the request does not contain a Policy-ID
header field with the local policy server URI as a value. If the
request does not contain such a header field or a local policy server
URI is not present in this header field, then the proxy MAY reject
the request with a 488 (Not Acceptable Here) response. The proxy
MUST insert a Policy-Contact header field in the 488 (Not Acceptable
Here) response that contains one (or multiple) URI(s) of its
Hilt, et al. Standards Track [Page 17]
RFC 6794 Session Policy Framework December 2012
associated policy server. The proxy MAY add the header field
parameter "non-cacheable" to prevent the UAC from caching this policy
server URI (see Section 4.4.4).
More than one URI for the policy server using different URI schemes
MAY be provided by the proxy as alternative URIs to contact the
policy. If a proxy includes multiple URIs for the same policy, the
proxy MUST include an "alt-uri" parameter for all policy server URIs
that are alternatives for obtaining the same policy. The "alt-uri"
parameter MUST contain either the domain name of the domain for which
all the alternative policy server URIs relate to or a Fully Qualified
Domain Name (FQDN) (e.g., the hostname of a policy server). All URIs
that are alternatives for the same policy MUST have the same value
for the "alt-uri" parameter. The value used for the "alt-uri"
parameter MUST be such that the same value will not be included with
other policy server URIs that a UA needs to contact by any other
proxy within the same domain or another domain. A method to create a
new unique "alt-uri" parameter value is to examine the value of
existing "alt-uri" parameters and to make sure that the new value
differs. A proxy MAY hint to a UA at a preference as to which URI to
use by including the more preferred URI higher in the list than the
other alternative URIs. URIs with the same "alt-uri" parameter MUST
use different URI schemes. A SIP or SIPS URI MUST be included even
if other URI schemes are defined and used in the future.
If a local policy server URI is present in a Policy-ID header field
value of a request, then the proxy MUST NOT reject the request as
described above (it can still reject the request for other reasons).
The proxy SHOULD remove the Policy-ID header field value of its
associated policy server from the Policy-ID header field before
forwarding the request. Not removing the Policy-ID header field
value will not cause harm; however, the value is not relevant to any
other proxy on the path and only increases message size. It also
would disclose the policy server URI to subsequent proxies.
The Policy-ID header field serves two main purposes: first and most
important, it enables the proxy to determine if a UAC already knows
the URI of the local policy server. The second purpose of the
Policy-ID header field is to enable a domain to route all requests
that belong to the same session (i.e., the initial request and
requests a UA retransmits after contacting the policy server) to the
same proxy and policy server. This is important if a domain has
multiple proxy/policy server combinations (e.g., in a proxy/policy
server farm that receives requests through a load balancer), which
create per-session state in the network. An example for such a
scenario is a policy server that is associated with a session border
device. The policy server configures the session border device after
receiving a session description from the UAC via the policy channel.
Hilt, et al. Standards Track [Page 18]
RFC 6794 Session Policy Framework December 2012
Retransmitted requests for such a session need to be routed to the
same proxy/policy server as the initial request since this proxy/
policy server combination has configured the associated border device
for the session.
Routing all requests that belong to the same session to the same
proxy can be achieved by using the Policy-ID header field token. It
requires that the policy server return a token to the UAC that
uniquely identifies the specific proxy/policy server combination.
The UAC includes this token in the Policy-ID header field, and it can
be used (together with the policy server URI) by the proxies in this
domain to route the request along the desired path. The format of
this token does not require standardization. The only requirement is
that the token provide sufficient information for proxies to route
the message inside a domain to the desired proxy/policy server. The
token can, for example, be a numeric identifier or an IP address.
Note: it has been proposed to use the Policy-ID header field to
provide a hint for a proxy that the UAC has actually contacted the
policy server. This usage also requires the policy server to
return a token to the UA. In addition, the policy server needs to
share valid tokens with the proxy. After receiving a request with
a Policy-ID header field, the proxy can determine if the token in
the Policy-ID header field is valid. If it is valid, the proxy
knows that the UA has contacted the policy server for this
session. However, this token does not provide any proof that the
UA has actually used the policies it has received from the policy
server. A malicious UA can simply contact the policy server,
discard all policies it receives, and still use the token in the
Policy-ID header field.
The proxy MAY insert a Policy-Contact header field into INVITE,
UPDATE, or PRACK requests (or any other request that can initiate an
offer/answer exchange) in order to convey the policy server URI to
the UAS. If the request already contains a Policy-Contact header
field, the proxy MUST insert the URI after all existing values at the
end of the list. A proxy MUST NOT change the order of existing
Policy-Contact header field values.
A proxy MUST use the Record-Route mechanism [RFC3261] if its
associated policy server has session policies that apply to mid-
dialog requests. The Record-Route header field enables a proxy to
stay in the signaling path and resubmit the policy server URIs to UAs
during mid-dialog requests that initiate an offer/answer exchange.
Resubmitting the policy server URI to UAs ensures that UAs keep
contacting the policy server for mid-dialog requests.
Hilt, et al. Standards Track [Page 19]
RFC 6794 Session Policy Framework December 2012
A proxy can find out if the UAS supports this extension by examining
the Supported header field of responses. The proxy knows that the
UAS supports this extension if the Supported header field of a
response contains the option tag "policy". A proxy can use this
information to determine if the UAS has understood the Policy-Contact
header field it has inserted into the request.
To protect the integrity of the policy server URI in a Policy-Contact
header field, the proxy SHOULD use a secured transport protocol such
as TLS [RFC5246] between proxy and UAs.
4.4.3. UAS Behavior
A UAS can receive an INVITE, UPDATE, or PRACK request (or another
request that can initiate offer/answer exchanges) that contains a
Policy-Contact header field with a list of policy server URIs. A UAS
that receives such a request needs to decide if it wants to accept
the session knowing that there are policy servers involved. If the
Policy-Contact header contains multiple URIs, each with a different
URI scheme and containing an "alt-uri" parameter with identical
values, these URI schemes represent alternative policy channel
mechanisms for obtaining the same policy. If the UAS accepts the
session, the UAS MUST contact one URI out of each group of URIs with
identical "alt-uri" parameter values to obtain the policy. The UAS
MAY take as a hint the order of the alternative URIs as indicating a
preference as to which URI to use. The topmost URI in the list might
be more preferred by the domain of the proxy for use to obtain the
policy. The UAS MUST contact all policy server URIs in a Policy-
Contact header field that are not part of a group of alternative URIs
and MUST contact one URI in each group of alternative URIs. The UAS
MUST contact these policy server URIs in the order in which they were
contained in the Policy-Contact header field, starting with the
topmost value (i.e., the value that was inserted first).
If a UAS decides that it does not want to accept a session because
there are policy servers involved or because one of the session
policies received from a policy server is not acceptable, the UAS
MUST reject the request with a 488 (Not Acceptable Here) response.
The UAS MAY accept a request and continue with setting up a session
if it cannot set up a policy channel to the policy server, for
example, because the policy server is unreachable or returns an error
condition that cannot be resolved by the UAS (i.e., error conditions
other than, for example, a 401 (Unauthorized) response). This is to
avoid that the failure of a policy server prevents a UA from
communicating. Since this session might not be policy compliant
without the policy subscription, it can be blocked by policy
enforcement mechanisms if they are in place.
Hilt, et al. Standards Track [Page 20]
RFC 6794 Session Policy Framework December 2012
A UAS can receive a token from a policy server via the policy
channel. Since the UAS does not create a Policy-ID header field, it
can simply ignore this token.
A UAS compliant to this specification MUST include a Supported header
field with the option tag "policy" into responses to requests that
can initiate an offer/answer exchange. The UAS MAY include this
option tag in all responses. This way, a proxy that has inserted the
Policy-Contact header field can know that the header field was
understood by the UAS.
4.4.4. Caching the Local Policy Server URI
A UAC frequently needs to contact the policy server in the local
domain before setting up a session. To avoid the retransmission of
the local policy server URI for each session, a UA SHOULD maintain a
cache that contains the URI of the local policy server.
A UA can receive this URI in a Policy-Contact header field of a
request or a 488 (Not Acceptable Here) response. The UA can also
receive the local policy server URI through configuration, for
example, via the configuration framework [RFC6080]. If a UA has
received a local policy server URI through configuration and receives
another local policy server URI in a Policy-Contact header field, the
UA SHOULD overwrite the configured URI with the most recent one
received in a Policy-Contact header field. A policy server URI
received in a Policy-Contact header field expires if it has not been
refreshed before it reaches the maximum cached URI validity. The
default maximum cached URI validity is 24 hours.
Domains can prevent a UA from caching the local policy server URI.
This is useful, for example, if the policy server does not need to be
involved in all sessions or the policy server URI changes from
session to session. A proxy can mark the URI of such a policy server
as "non-cacheable". A UA MUST NOT cache a non-cacheable policy
server URI. The UA SHOULD remove the current URI from the cache when
receiving a local policy server URI that is marked as "non-
cacheable". This is to avoid the use of policy server URIs that are
outdated.
The UA SHOULD NOT cache policy server URIs it has received from
proxies outside of the local domain. These policy servers need not
be relevant for subsequent sessions, which can go to a different
destination, traversing different domains.
The UA MUST NOT cache tokens it has received from a policy server. A
token is only valid for one request.
Hilt, et al. Standards Track [Page 21]
RFC 6794 Session Policy Framework December 2012
4.4.5. Header Field Definition and Syntax
4.4.5.1. Policy-ID Header Field
The Policy-ID header field is inserted by the UAC into INVITE,
UPDATE, or PRACK requests (or any other request that can be used to
initiate an offer/answer exchange). The Policy-ID header field
identifies all policy servers the UAC has contacted for this request.
The value of a Policy-ID header field consists of a policy server URI
and an optional token parameter. The token parameter contains a
token the UA might have received from the policy server.
The syntax of the Policy-ID header field is described below in ABNF,
according to [RFC5234], as an extension to the ABNF for SIP in
[RFC3261]:
Policy-ID = "Policy-ID" HCOLON policyURI
*(COMMA policyURI)
policyURI = ( SIP-URI / SIPS-URI / absoluteURI )
[ SEMI token-param ] *( SEMI generic-param )
token-param = "token=" token
4.4.5.2. Policy-Contact Header Field
The Policy-Contact header field can be inserted by a proxy into a 488
(Not Acceptable Here) response to INVITE, UPDATE, or PRACK requests
(or other requests that initiate an offer/answer exchange). The
value of a Policy-Contact header field consists of a policy server
URI and an optional "non-cacheable" header field parameter. The
policy server URI identifies the policy server that needs to be
contacted by a UAC. The "non-cacheable" header field parameter
indicates that the policy server URI is not intended to be cached by
the UAC.
The Policy-Contact header field can also be inserted by a proxy into
INVITE, UPDATE, and PRACK requests (or other requests that can be
used to initiate an offer/answer exchange). It contains an ordered
list of policy server URIs that need to be contacted by the UAS. The
topmost value of this list identifies the policy server that is
contacted first. New header field values are inserted at the end.
With this, the Policy-Contact header field effectively forms a fist-
in-first-out queue.
The syntax of the Policy-Contact header field is described below in
ABNF, according to [RFC5234], as an extension to the ABNF for SIP in
[RFC3261]:
Hilt, et al. Standards Track [Page 22]
RFC 6794 Session Policy Framework December 2012
Policy-Contact = "Policy-Contact" HCOLON policyContact-info
*(COMMA policyContact-info)
policyContact-info = LAQUOT policyContact-uri RAQUOT
*( SEMI policyContact-param )
policyContact-uri = ( SIP-URI / SIPS-URI / absoluteURI )
policyContact-param = ( "non-cacheable" / policyContact-alt-uri
/ generic-param )
policyContact-alt-uri = "alt-uri" EQUAL hostname
Tables 1 and 2 are extensions of Tables 2 and 3 in [RFC3261]. The
column "INF" is for the INFO method [RFC6086], "PRA" is for the PRACK
method [RFC3262], "UPD" is for the UPDATE method [RFC3311], "SUB" is
for the SUBSCRIBE method [RFC6665], "NOT" is for the NOTIFY method
[RFC6665], "MSG" is for the MESSAGE method [RFC3428], "REF" is for
the REFER method [RFC3515], and "PUB" is for the PUBLISH method
[RFC3903].
Header field where proxy ACK BYE CAN INV OPT REG UPD
_______________________________________________________________
Policy-ID R rd - - - c - - c
Policy-Contact R a - - - c - - c
Policy-Contact 488 a - - - c - - c
Table 1: Policy-ID and Policy-Contact Header Fields
Header field where proxy PRA PUB SUB NOT INF MSG REF
_______________________________________________________________
Policy-ID R rd c - - - - - -
Policy-Contact R a c - - - - - -
Policy-Contact 488 a c - - - - - -
Table 2: Policy-ID and Policy-Contact Header Fields
4.5. Policy Channel
The main task of the policy channel is to enable a UA to submit
information about the session it is trying to establish (i.e., the
offer and the answer) to a policy server and to receive the resulting
session-specific policies and possible updates to these policies in
response.
The Event Package for Session-Specific Policies [RFC6795] defines a
SUBSCRIBE/NOTIFY-based [RFC6665] policy channel mechanism. A UA
compliant to this specification MUST support the Event Package for
Session-Specific Policies [RFC6795]. The UA MUST use this event
Hilt, et al. Standards Track [Page 23]
RFC 6794 Session Policy Framework December 2012
package to contact a policy server if the policy server URI is a
SIP-URI or SIPS-URI. A UA MAY support other policy channel
mechanisms.
4.5.1. Creation and Management
A UA discovers the list of policy servers relevant for a session
during the initial offer/answer exchange (see Section 4.4). A UA
compliant to this specification MUST set up a policy channel to each
of the discovered policy servers. If the UA does not want to set up
a policy channel to one of the policy servers provided, the UA MUST
cancel or reject a pending INVITE transaction for the session or
terminate the session if it is already in progress.
A UA MUST maintain the policy channel to each discovered policy
server during the lifetime of a session, unless the policy channel is
closed by the policy server or the UA discovers that the policy
server is no longer relevant for the session as described below.
A UAC can receive a 488 (Not Acceptable Here) response with a Policy-
Contact header field containing a new policy server URI in response
to a mid-dialog request. This indicates that the set of policy
servers relevant for the current session has changed. If this
occurs, the UAC MUST retry sending the request as if it were the
first request in a dialog (i.e., without applying any policies except
the policies from the local policy server). This way, the UAC will
rediscover the list of policy servers for the current session. This
is necessary since the UAC has no other way of knowing when to
contact the newly discovered policy server relative to the existing
policy servers and if any of the existing policy servers do not need
to be contacted any more. The UAC MUST set up a policy channel to
each new policy server. The UAC SHOULD close policy channels to
policy server that are not listed any more. If the policy channel to
these servers is not closed, the UAC can receive policies that do not
apply to the session any more. The UAC MUST contact policy servers
in the order in which they were discovered in the most recent
request.
If a UAS receives a mid-dialog request with a Policy-Contact header
field containing a list of policy server URIs that is different from
the list of policy servers to which the UAS has currently established
a policy channel, then the UAS MUST set up a policy channel to all
new policy servers and contact them. The UAS SHOULD close policy
channels to servers that are not listed any more. If the policy
channel to these servers is not closed, the UAS can receive policies
that do not apply to the session any more. The UAS MUST use policy
servers in the order in which they were contained in the most recent
Policy-Contact header field.
Hilt, et al. Standards Track [Page 24]
RFC 6794 Session Policy Framework December 2012
A UA MUST inform the policy server when a session is terminated
(e.g., when the UA has either sent or received a BYE) via the policy
channel, unless a policy server indicates via the policy channel that
it does not need to be contacted at the end of the session. This
enables a policy server to free all resources it has allocated for
this session.
4.5.2. Contacting the Policy Server
A UA MUST contact all policy servers to which it has established a
policy channel before sending or after receiving a mid-dialog
request. The UA MUST contact the policy servers in the order in
which they were discovered most recently.
A UA that receives a SIP message containing an offer or answer SHOULD
completely process the message (e.g., according to [RFC3261]) before
contacting the policy server. The SIP processing of the message
includes, for example, updating dialog state and timers as well as
creating ACK or PRACK requests as necessary. This ensures that
contacting a policy server does not interfere with SIP message
processing and timing (e.g., by inadvertently causing timers to
expire). This implies, for example, that a UAC that has received a
response to an INVITE request would normally finish the processing of
the response including transmitting the ACK request before it
contacts the policy server. An important exception to this rule is
discussed in the next paragraph.
In some cases, a UA needs to use the offer/answer it has received in
a SIP message to create an ACK or PRACK request for this message;
i.e., it needs to use the offer/answer before finishing the SIP
machinery for this message. For example, a UAC that has received an
offer in the response to an INVITE request needs to apply policies to
the offer and the answer before it can send the answer in an ACK
request. In these cases, a UA SHOULD contact the policy server even
if this is during the processing of a SIP message. This implies that
a UA, which has received an offer in the response of an INVITE
request, would normally contact the policy server and apply session
policies before sending the answer in the ACK request.
Note: this assumes that the policy server can always respond
immediately to a policy request and does not require manual
intervention to create a policy. This will be the case for most
policy servers. If, however, a policy server cannot respond with
a policy right away, it can return a policy that temporarily
denies the session and update this policy as the actual policy
decision becomes available. A delay in the response from the
Hilt, et al. Standards Track [Page 25]
RFC 6794 Session Policy Framework December 2012
policy server to the UA would delay the transmission of the ACK
request and could trigger retransmissions of the INVITE response
(also see the recommendations for Flow I in [RFC3725]).
The case of multiple policy servers providing policies to the same UA
requires additional considerations. A policy returned by one policy
server can contain information that needs to be shared with the other
policy servers. For example, two policy servers can have the policy
to insert a media intermediary by modifying the IP addresses and
ports of media streams. In order for media streams to pass through
both intermediaries, each intermediary needs to know the IP address
and port on which the other media intermediary is expecting the
stream to arrive. If media streams are flowing in both directions,
this means that each intermediary needs to know IP addresses and
ports of the other intermediary.
UACs usually contact a policy server twice during an offer/answer
exchange (unless a policy server indicates that it only needs to be
contacted once). Therefore, the case of multiple policy servers
providing policies to a single UAC does not require additional steps
in most cases. However, a UAS usually contacts each policy server
only once (see Figure 4). If a session policy returned by one of the
policy servers requires that information be shared between multiple
servers and the UAS receives policies from more than one policy
server, then the UAS MUST contact all policy servers a second time
after contacting all servers the first time. Whether or not a second
round is required is determined by the type of information returned
by the policy server. A data format for session policies (e.g.,
[RFC6796]) needs to explicitly state if a second round is needed for
a particular data element. If a UA receives such an element, it
knows that is expected to contact policy servers a second time. If
such a data element is modified during a mid-call offer/answer
exchange and multiple policy servers are providing policies to a UA,
then all UAs MUST contact policy servers in a first and second round.
An example call flow is shown in Appendix B.3.
A UA that supports session-specific policies compliant to this
specification MUST support the User Agent Profile Data Set for Media
Policy [RFC6796] as data format for session policies.
4.5.3. Using Session Policies
A UA MUST disclose the session description(s) for the current session
to policy servers through the policy channel. The UA MUST apply
session policies it receives to the offer and, if one is received, to
the answer before using the offer/answer. If these policies are
unacceptable, the UA MUST NOT continue with the session. This means
that the UA MUST cancel or reject a pending INVITE transaction for
Hilt, et al. Standards Track [Page 26]
RFC 6794 Session Policy Framework December 2012
the session or terminate the session if it is already in progress.
If the UA receives an unacceptable policy in an INVITE response, the
UA MUST complete the INVITE transaction and then terminate the
session.
When a UA receives a notification about a change in the current
policies, the UA MUST apply the updated policies to the current
session or the UA MUST terminate the session. If the policy update
causes a change in the session description of a session, then the UA
needs to renegotiate the modified session description with its peer
UA, for example, using a re-INVITE or UPDATE request. For example,
if a policy update disallows the use of video and video is part of
the current session description, then the UA will need to create an
new session description offer without video. After receiving this
offer, the peer UA knows that video can't be used any more and
responds with the corresponding answer.
5. Security Considerations
Policy enforcement mechanisms can prevent a UA from communicating
with another UA if the UAs are not aware of the policies that are
enforced. Policy enforcement mechanisms without policy signaling can
therefore create a denial-of-service condition for UAs. This
specification provides a mechanism for intermediaries to signal the
policies that are enforced to UAs. It enables UAs to establish
sessions that are conform and pass through policy enforcement.
Session policies can significantly change the behavior of a UA and
can be used by an attacker to compromise a UA. For example, session
policies can be used to prevent a UA from successfully establishing a
session (e.g., by setting the available bandwidth to zero). Such a
policy can be submitted to the UA during a session, which causes the
UA to terminate the session.
A UA transmits session information to a policy server for session-
specific policies. This session information can contain sensitive
data the user does not want an eavesdropper or an unauthorized policy
server to see. Vice versa, session policies can contain sensitive
information about the network or service level agreements the service
provider does not want to disclose to an eavesdropper or an
unauthorized UA.
It is important to secure the communication between the proxy and the
UA (for session-specific policies) as well as the UA and the policy
server. The following four discrete attributes need to be protected:
1. integrity of the policy server URI (for session-specific
policies),
Hilt, et al. Standards Track [Page 27]
RFC 6794 Session Policy Framework December 2012
2. authentication of the policy server and, if needed, the user
agent,
3. confidentiality of the messages exchanged between the user agent
and the policy server and
4. ensuring that private information is not exchanged between the
two parties, even over a confidentiality-assured and
authenticated session.
To protect the integrity of the policy server URI, a UA SHOULD use a
secured transport protocol such as TLS [RFC5246] between proxies and
the UA. Protecting the integrity of the policy server URI is
important since an attacker could intercept SIP messages between the
UA and the proxy and remove the policy header fields needed for
session-specific policies. This would impede the rendezvous between
UA and policy server and, since the UA would not contact the policy
server, can prevent a UA from setting up a session.
Instead of removing a policy server URI, an attacker can also modify
the policy server URI and point the UA to a compromised policy
server. It is RECOMMENDED that a UA authenticate policy servers to
prevent such an attack from being effective.
It is RECOMMENDED that the UA only accept session-independent
policies from trustworthy policy servers as these policies affect all
sessions of a UA. A list of trustworthy session-independent policy
servers can be provided to the UA through configuration. As SIP
messages can be affected by any proxy on a path and session-specific
policies only apply to a single session, a UA MAY choose to accept
session-specific policies from other policy servers as well.
Policy servers SHOULD authenticate UAs to protect the information
that is contained in a session policy. However, a policy server can
also frequently encounter UAs it cannot authenticate. In these
cases, the policy server MAY provide a generic policy that does not
reveal sensitive information to these UAs.
It is RECOMMENDED that administrators use SIPS URIs as policy server
URIs so that subscriptions to session policies are transmitted over
TLS.
The above security attributes are important to protect the
communication between the UA and policy server. This document does
not define the protocol used for the communication between UA and
policy server and merely refers to other specifications for this
purpose. The security considerations of these specifications need to
address the above security aspects.
Hilt, et al. Standards Track [Page 28]
RFC 6794 Session Policy Framework December 2012
6. IANA Considerations
6.1. Registration of the "Policy-ID" Header Field
Name of Header Field: Policy-ID
Short form: none
Normative description: Section 4.4.5 of this document
6.2. Registration of the "Policy-Contact" Header Field
Name of Header Field: Policy-Contact
Short form: none
Normative description: Section 4.4.5 of this document
6.3. Registration of the "non-cacheable" Policy-Contact Header Field
Parameter
Registry Name: Header Field Parameters and Parameter Values
Reference: [RFC3968]
Registry:
Header Field Parameter Name Predefined Reference
Values
_____________________________________________________________________
Policy-Contact non-cacheable Yes this document
6.4. Registration of the "policy" SIP Option Tag
This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of [RFC3261].
This document defines the SIP option tag "policy".
The following row has been added to the "Option Tags" section of the
SIP Parameter Registry:
Hilt, et al. Standards Track [Page 29]
RFC 6794 Session Policy Framework December 2012
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| policy | This option tag is used to indicate that | this |
| | a UA can process policy server URIs for | document |
| | and subscribe to session-specific | |
| | policies. | |
+------------+------------------------------------------+-----------+
Name of option: policy
Description: Support for the Policy-Contact and Policy-ID header
fields.
SIP header fields defined: Policy-Contact, Policy-ID
Normative description: This document
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Hilt, et al. Standards Track [Page 30]
RFC 6794 Session Policy Framework December 2012
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
RFC 6080, March 2011.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
July 2012.
[RFC6795] Hilt, V. and G. Camarillo, "A Session Initiation Protocol
(SIP) Event Package for Session-Specific Policies",
RFC 6795, December 2012.
[RFC6796] Hilt, V., Camarillo, G., Rosenberg, J., and D. Worley, "A
User Agent Profile Data Set for Media Policy", RFC 6796,
December 2012.
7.2. Informative References
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, January 2011.
Hilt, et al. Standards Track [Page 31]
RFC 6794 Session Policy Framework December 2012
Appendix A. Acknowledgements
Many thanks to Allison Mankin, Andrew Allen, Cullen Jennings and
Vijay Gurbani for their contributions to this document. Many thanks
to Roni Even, Bob Penfield, Mary Barnes, Shida Schubert, Keith Drage,
Lisa Dusseault, Tim Polk and Pasi Eronen for their reviews and
suggestions.
Appendix B. Session-Specific Policies - Call Flows
The following call flows illustrate the overall operation of session-
specific policies including the policy channel protocol as defined in
"A Session Initiation Protocol (SIP) Event Package for Session-
Specific Policies" [RFC6795].
The following abbreviations are used:
o: offer
o': offer modified by a policy
po: offer policy
a: answer
a': answer modified by a policy
pa: answer policy
ps uri: policy server URI (in Policy-Contact header field)
ps id: policy server id (in Policy-ID header field)
B.1. Offer in Invite
Hilt, et al. Standards Track [Page 32]
RFC 6794 Session Policy Framework December 2012
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE <o> | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY <po> | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id, o'>| | | |
|-------->| | | | |
| |(9) INV <o'> | | |
| |---------------------------->| |
| | | | |(10) INV <o', ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o', a>
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po, pa>
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <a'>
| | | | |<--------|
| |(16) 200 OK <a'> | | |
| |<----------------------------| |
|(17) 200 OK <a'> | | | |
|<--------| | | | |
|(18) ACK | | | | |
|------------------------------------------------>|
|(19) SUBSCRIBE <o', a'> | | |
|------------------>| | | |
|(20) 200 OK | | | |
|<------------------| | | |
|(21) NOTIFY <po, pa> | | |
|<------------------| | | |
|(22) 200 OK | | | |
|------------------>| | | |
| | | | | |
| | | | | |
Hilt, et al. Standards Track [Page 33]
RFC 6794 Session Policy Framework December 2012
B.2. Offer in Response
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV | | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id> | | | |
|-------->| | | | |
| |(9) INV | | | |
| |---------------------------->| |
| | | | |(10) INV <ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o> |
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po> |
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <o'>
| | | | |<--------|
| |(16) 200 OK <o'> | | |
| |<----------------------------| |
|(17) 200 OK <o'> | | | |
|<--------| | | | |
|(18) SUBSCRIBE <o', a> | | |
|------------------>| | | |
|(19) 200 OK | | | |
|<------------------| | | |
|(20) NOTIFY <po, pa> | | |
|<------------------| | | |
|(21) 200 OK | | | |
|------------------quot;, [RFC6235], which describes
anonymization techniques for IP flow data and the export of
anonymized data using the IPFIX protocol.
2. "Flow Selection Techniques" [RFC7014], which describes the
process of selecting a subset of Flows from all Flows observed at
an Observation Point, the flow selection motivations, and some
specific flow selection techniques.
3. "Flow Aggregation for the IP Flow Information Export (IPFIX)
Protocol" [RFC7015], which describes Aggregated Flow export
within the framework of IPFIX Mediators and defines an
interoperable, implementation-independent method for Aggregated
Flow export.
Claise, et al. Standards Track [Page 4]
RFC 7119 IPFIX MED-PROTO February 2014
This document specifies the IP Flow Information Export (IPFIX)
protocol specific to Mediation, to which all Intermediate Processes
must comply. Some extra specifications might be required per
Intermediate Process type (in which case, the document specific to
the Intermediate Process would apply).
1.3. Relationship with the IPFIX and PSAMP Protocols
The specification in this document is based on the IPFIX protocol
specification [RFC7011]. All specifications from [RFC7011] apply
unless specified otherwise in this document.
As the Packet Sampling (PSAMP) protocol specifications [RFC5476] are
based on the IPFIX protocol specifications, the specifications in
this document are also valid for the PSAMP protocol. Therefore, the
method specified by this document also applies to PSAMP.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
IPFIX-specific terms, such as Observation Domain, Flow, Flow Key,
Metering Process, Exporting Process, Exporter, IPFIX Device,
Collecting Process, Collector, Template, IPFIX Message, Message
Header, Template Record, Data Record, Options Template Record, Set,
Data Set, Information Element, Scope and Transport Session, used in
this document are defined in [RFC7011]. The PSAMP-specific terms
used in this document, such as Filtering and Sampling, are defined in
[RFC5476].
IPFIX Mediation terms related to aggregation, such as the Interval,
Aggregated Flow and Aggregated Function, are defined in [RFC7015].
The terminology specific to IPFIX Mediation that is used in this
document is defined in "IP Flow Information Export (IPFIX) Mediation:
Problem Statement" [RFC5982] and reused in "IP Flow Information
Export (IPFIX) Mediation: Framework" [RFC6183]. However, since both
of those documents are Informational RFCs, the definitions have been
reproduced and elaborated on here.
Similarly, since [RFC6235] is an Experimental RFC, the Anonymization
Record, Anonymized Data Record, and Intermediate Anonymization
Process terms, specified in [RFC6235], are also reproduced here.
Claise, et al. Standards Track [Page 5]
RFC 7119 IPFIX MED-PROTO February 2014
In this document, as in [RFC7011], [RFC5476], [RFC7015], and
[RFC6235], the first letter of each IPFIX-specific and PSAMP-specific
term is capitalized along with the IPFIX Mediation-specific term
defined here.
In this document, we call a stream of records carrying flow- or
packet-based information a "record stream". The records may be
encoded as IPFIX Data Records or any other format.
Transport Session: The Transport Session is specified in [RFC7011].
In Stream Control Transmission Protocol (SCTP), the Transport
Session information is the SCTP association. In TCP and UDP, the
Transport Session information corresponds to a 5-tuple {Exporter
IP address, Collector IP address, Exporter transport port,
Collector transport port, transport protocol}.
Original Exporter: An Original Exporter is the source from which a
Mediator receives its record stream. For simple IPFIX mediation
without protocol conversion, this is an IPFIX Device that hosts
the Observation Points where the metered IP packets are observed.
Original Observation Point: An Observation Point on a Metering
Process associated with the Original Exporter. In the case of the
Intermediate Aggregation Process on an IPFIX Mediator, the
Original Observation Point can be composed of, but not limited to,
a (set of) specific Exporter(s), a (set of) specific interface(s)
on an Exporter, a (set of) line card(s) on an Exporter, or any
combinations of these.
IPFIX Mediation: IPFIX Mediation is the manipulation and conversion
of a record stream for subsequent export using the IPFIX protocol.
Template Mapping: A mapping from Template Records and/or Options
Template Records received by an IPFIX Mediator to Template Records
and/or Options Template Records sent by that IPFIX Mediator. Each
entry in a Template Mapping is scoped by incoming or outgoing
Transport Session and Observation Domain, as with Templates and
Options Templates in the IPFIX Protocol.
Anonymization Record: A record that defines the properties of the
anonymization applied to a single Information Element within a
single Template or Options Template, as in [RFC6235].
Anonymized Data Record: A Data Record within a Data Set containing
at least one Information Element with anonymized values. The
Information Element(s) within the Template or Options Template
describing this Data Record SHOULD have a corresponding
Anonymization Record, as in [RFC6235].
Claise, et al. Standards Track [Page 6]
RFC 7119 IPFIX MED-PROTO February 2014
The following terms are used in this document to describe the
architectural entities used by IPFIX Mediation.
Intermediate Process: An Intermediate Process takes a record stream
as its input from Collecting Processes, Metering Processes, IPFIX
File Readers, other Intermediate Processes, or other record
sources; performs some transformations on this stream, based upon
the content of each record, states maintained across multiple
records, or other data sources; and passes the transformed record
stream as its output to Exporting Processes, IPFIX File Writers,
or other Intermediate Processes, in order to perform IPFIX
Mediation. Typically, an Intermediate Process is hosted by an
IPFIX Mediator. Alternatively, an Intermediate Process may be
hosted by an Original Exporter.
IPFIX Mediator: An IPFIX Mediator is an IPFIX Device that provides
IPFIX Mediation by receiving a record stream from some data
sources, hosting one or more Intermediate Processes to transform
that stream, and exporting the transformed record stream into
IPFIX Messages via an Exporting Process. In the common case, an
IPFIX Mediator receives a record stream from a Collecting Process,
but it could also receive a record stream from data sources not
encoded using IPFIX, e.g., in the case of conversion from the
NetFlow V9 protocol [RFC3954] to IPFIX protocol.
Specific Intermediate Processes are described below.
Intermediate Conversion Process (as in [RFC6183]): An Intermediate
Conversion Process is an Intermediate Process that transforms non-
IPFIX into IPFIX or manages the relation among Templates and
states of incoming/outgoing Transport Sessions in the case of
transport protocol conversion (e.g., from UDP to SCTP).
Intermediate Aggregation Process (as in [RFC7015]): an Intermediate
Process (IAP), as in [RFC6183], that aggregates records, based
upon a set of Flow Keys or functions applied to fields from the
record.
Intermediate Correlation Process (as in [RFC6183]): An Intermediate
Correlation Process is an Intermediate Process that adds
information to records, noting correlations among them, or
generates new records with correlated data from multiple records
(e.g., the production of bidirectional flow records from
unidirectional flow records).
Intermediate Anonymization Process (as in [RFC6235]): An
intermediate process that takes Data Records and transforms them
into Anonymized Data Records.
Claise, et al. Standards Track [Page 7]
RFC 7119 IPFIX MED-PROTO February 2014
Intermediate Selection Process (as in [RFC6183]): An Intermediate
Selection Process is an Intermediate Process that selects records
from a sequence based upon criteria-evaluated record values and
passes only those records that match the criteria (e.g., Filtering
only records from a given network to a given Collector).
Intermediate Flow Selection Process (as in [RFC7014]: An
Intermediate Flow Selection Process is an Intermediate Process, as
in [RFC6183] that takes Flow Records as its input and selects a
subset of this set as its output. The Intermediate Flow Selection
Process is a more general concept than the Intermediate Selection
Process as defined in [RFC6183]. While an Intermediate Selection
Process selects Flow Records from a sequence based upon criteria-
evaluated Flow record values and only passes on those Flow Records
that match the criteria, an Intermediate Flow Selection Process
selects Flow Records using selection criteria applicable to a
larger set of Flow characteristics and information.
Note: for more information on the difference between Intermediate
Flow Selection Process and Intermediate Selection Process, see
Section 4 in [RFC7014].
3. Handling IPFIX Message Headers
The format of the IPFIX Message Header as exported by an IPFIX
Mediator is shown in Figure 1. This is identical to the format
defined for IPFIX in [RFC7011], though Export Time and Observation
Domain ID may be handled differently at certain Mediators, as noted
below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPFIX Message Header format
Claise, et al. Standards Track [Page 8]
RFC 7119 IPFIX MED-PROTO February 2014
The header fields as exported by an IPFIX Mediator are described
below.
Version:
Version of IPFIX to which this Message conforms. The value of
this field is 0x000a for the current version, incrementing by one
the version used in the NetFlow services export version 9
[RFC3954].
Length:
Total length of the IPFIX Message, measured in octets, including
Message Header and Set(s).
Export Time:
Time at which the IPFIX Message Header leaves the IPFIX Mediator,
expressed in seconds since the UNIX epoch of 1 January 1970 at
00:00 UTC, encoded as an unsigned 32-bit integer.
However, in the specific case of an IPFIX Mediator containing an
Intermediate Conversion Process, the IPFIX Mediator MAY use the
export time received from the incoming Transport Session.
Sequence Number:
Incremental sequence counter modulo 2^32 of all IPFIX Data Records
sent in the current stream from the current Observation Domain by
the Exporting Process. Each SCTP Stream counts sequence numbers
separately, while all messages in a TCP connection or UDP
Transport Session are considered to be part of the same stream.
This value can be used by the Collecting Process to identify
whether any IPFIX Data Records have been missed. Template and
Options Template Records do not increase the Sequence Number.
Observation Domain ID:
A 32-bit identifier of the Observation Domain that is locally
unique to the Exporting Process. The Exporting Process uses the
Observation Domain ID to uniquely identify to the Collecting
Process the Observation Domain that metered the Flows. It is
RECOMMENDED that this identifier also be unique per IPFIX Device.
Collecting Processes can use the Transport Session and the
Observation Domain ID field to separate different export streams
originating from the same Exporter. The Observation Domain ID is
set to 0 when no specific Observation Domain ID is relevant for
Claise, et al. Standards Track [Page 9]
RFC 7119 IPFIX MED-PROTO February 2014
the entire IPFIX Message, for example, when exporting the
Exporting Process Statistics, or in case of a hierarchy of
Collectors when aggregated Data Records are exported.
See Section 4.1 for special considerations for Observation Domain
management while passing unmodified templates through an IPFIX
Mediator, and Section 5 for guidelines for preservation of
original Observation Domain information at an IPFIX Mediator.
The following specifications, copied over from [RFC7011] have some
implications in this document:
Template Withdrawals MAY appear interleaved with Template Sets,
Options Template Sets, and Data Sets within an IPFIX Message. In
this case, the Templates and Template Withdrawals shall be
interpreted as taking effect in the order in which they appear in
the IPFIX Message.
If an IPFIX Mediator receives an IPFIX Message composed of Template
Withdrawals and Template Sets, and if the IPFIX Mediator forwards
this IPFIX Message, it MUST NOT modify the Set order. If an IPFIX
Mediator receives IPFIX Messages composed of Template Withdrawals and
Template Sets, and if the IPFIX Mediator forwards these IPFIX
Messages, it MUST NOT modify the IPFIX Message order. Note that the
Template Mapping (see Section 4.1) is the authoritative source of
information on the IPFIX Mediator to decide whether the entire IPFIX
Messages can be forwarded as such.
4. Template Management
How an IPFIX Mediator handles the Templates it receives from the
Original Exporter depends entirely on the nature of the Intermediate
Process running on that IPFIX Mediator. There are two cases here:
1. IPFIX Mediators that pass substantially the same Data Records
from the Original Exporter downstream (e.g., an Intermediate
Selection Process), pass unmodified Templates as described in
Section 4.1; this section describes a Template Mapping required
to make this work in the general case, and the correlation
between the received and generated IPFIX Message Withdrawals.
2. IPFIX Mediators that export Data Records that are substantially
changed from the Data Records received from the Original Exporter
follow the guidelines in Section 4.2 instead: in this case, the
IPFIX Mediator generates new (Options) Template Records as a
result of the Intermediate Process, and no Template Mapping is
required.
Claise, et al. Standards Track [Page 10]
RFC 7119 IPFIX MED-PROTO February 2014
Subsequent subsections deal with specific issues in Template
management that may occur at IPFIX Mediators.
4.1. Passing Unmodified Templates through an IPFIX Mediator
For some Intermediate Processes, the IPFIX Mediator doesn't modify
the (Options) Template Record(s) content. A typical example is an
Intermediate Flow Selection Process acting as distributor, which
collects Flow Records from one or more Exporters, and based on the
content of the Information Elements, redirects the Flow Records to
the appropriate Collector. This example is a typical case of a
single network operation center managing multiple universities: a
unique IPFIX Collector collects all Flow Records for the common
infrastructure, but might be re-exporting specific university Flow
Records to the responsible system administrator.
As specified in [RFC7011], the Template IDs are unique per Exporter,
per Transport Session, and per Observation Domain. As there is no
guarantee that, for similar Template Records, the Template IDs
received on the incoming Transport Session and exported to the
outgoing Transport Session would be same, the IPFIX Mediator MUST
maintain a Template Mapping composed of related received and exported
(Options) Template Records:
o for each received (Options) Template Record: Template Record
Information Elements, Template ID, Observation Domain ID, and
Transport Session information, metadata scoped to the Template (*)
o for each exported (Options) Template Record: Template Record
Information Elements, Template ID, Collector, Observation Domain
ID, and Transport Session information metadata scoped to the
Template (*)
(*) The "metadata scoped to the Template" encompasses the metadata,
that are scoped to the Template, and that help to determine the
semantics of the Template Record. Note that these metadata are
typically sent in Data Records described by an Options Template. An
example is the flowKeyIndicator. An IPFIX Mediator could potentially
receive two different Template IDs, from the same Exporter, with the
same Information Elements, but with a different set of Flow Keys
(indicated by the flowKeyIndicator in an Options Template Record).
Another example is the combination of anonymizationFlags and
anonymizationTechnique [RFC6235]). This metadata information must be
present in the Template Mapping, to stress that the two Template
Record semantics are different.
Claise, et al. Standards Track [Page 11]
RFC 7119 IPFIX MED-PROTO February 2014
If an IPFIX Mediator receives an IPFIX Withdrawal Message for a
(Options) Template Record that is not used anymore in any other
Template Mappings, the IPFIX Mediator SHOULD export the appropriate
IPFIX Withdrawal Message(s) on the outgoing Transport Session and
remove the corresponding entry in the Template Mapping.
If a (Options) Template Record is not used anymore in an outgoing
Transport Session, it MUST be withdrawn with an IPFIX Template
Withdrawal Message on that specific outgoing Transport Session, and
its entry, MUST be removed from the Template Mapping.
If an incoming or outgoing Transport Session is gracefully shut down
or reset, the (Options) Template Records corresponding to that
Transport Session MUST be removed from the Template Mapping.
For example, Figure 2 displays an example of an Intermediate Flow
Selection Process, redistributing Data Records to Collectors on the
basis of customer networks, i.e., the Route Distinguisher (RD). In
this example, the Template Record received from the Exporter #1 is
reused towards Collector #1, Collector #2, and Collector #3, for the
customer #1, customer #2, and customer #3, respectively. In this
example, the outgoing Template Records exported to the different
Collectors are identical. As a reminder that the Template ID
uniqueness is local to the Transport Session and Observation Domain
that generated the Template ID, a mix of Template ID 256 and 257 has
been used.
Claise, et al. Standards Track [Page 12]
RFC 7119 IPFIX MED-PROTO February 2014
.---------.
Tmpl. | |
ID .---->|Collector|<==>Customer 1
256 | | #1 |
| | |
RD=100:1 '---------'
.--------. .--------. |
| | Tmpl. | |----'
| | Id | | .---------.
| | 258 | | RD=100:2 | |
| IPFIX |------->| IPFIX |--------->|Collector|<==>Customer 2
|Exporter| |Mediator| Tmpl. | #2 |
| #1 | | | ID 257 | |
| | | | '---------'
| | | |----.
'--------' '--------' |
RD=100:3
| .---------.
Tmpl. | | |
ID '---->|Collector|<==>Customer 3
257 | #3 |
| |
'---------'
Figure 2: Intermediate Flow Selection Process Example
Figure 3 shows the Template Mapping for the system shown in Figure 2.
Claise, et al. Standards Track [Page 13]
RFC 7119 IPFIX MED-PROTO February 2014
+-----------------------------------------------------------------+
| Template Entry A: |
| Incoming Transport Session information (from Exporter#1): |
| Source IP: <Exporter#1 export IP address> |
| Destination IP: <IPFIX Mediator IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 258 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry B: |
| Outgoing Transport Session information (to Collector#1): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#1 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 256 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry C: |
| Outgoing Transport Session information (to Collector#2): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#2 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 257 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry D: |
| Outgoing Transport Session information (to Collector#3): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#3 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 257 |
| Metadata scoped to the Template : <not applicable in this case> |
+-----------------------------------------------------------------+
Figure 3: Template Mapping Example: Templates
Claise, et al. Standards Track [Page 14]
RFC 7119 IPFIX MED-PROTO February 2014
The Template Mapping corresponding to Figure 3 is displayed in
Figure 4:
Template Entry A <----> Template Entry B
Template Entry A <----> Template Entry C
Template Entry A <----> Template Entry D
Figure 4: Template Mapping Example: Mappings
Alternatively, the Template Mapping may be optimized as in Figure 5:
+--> Template Entry B
|
Template Entry A <--+--> Template Entry C
|
+--> Template Entry D
Figure 5: Template Mapping Example 2: Mappings
Note that all examples use Transport Sessions based on the SCTP, as
simplified use cases. However, the transport protocol would be
important in situations such as an Intermediate Conversion Process
doing transport protocol conversion.
4.1.1. Template Mapping and Information Element Ordering
In the situation where Original Exporters each export an (Options)
Template Record to a single IPFIX Mediator, and the (Options)
Template Record contains the same Information Elements, but in
different order, should the IPFIX Mediator maintain a Template
Mapping with a single Export Template Record (see Figure 6) or should
the IPFIX Mediator maintain multiple independent Template Records
(see Figure 7) before re-exporting to the Collector?
Template Entry A <--+
|
Template Entry B <--+--> Template Entry D
|
Template Entry C <--+
Figure 6: Template Mapping and Ordering:
A single Export Template Record
Claise, et al. Standards Track [Page 15]
RFC 7119 IPFIX MED-PROTO February 2014
Template Entry A <--+--> Template Entry D
Template Entry B <--+--> Template Entry E
Template Entry C <--+--> Template Entry F
Figure 7: Template Mapping and Ordering:
Multiple Export Template Records
The answer depends on whether the order of the Information Elements
implies some specific semantic. One of the guiding principles in
IPFIX protocol specifications is that the semantic meaning of one
Information Element doesn't depend on the value of any other
Information Element. However, there is one noticeable exception, as
mentioned in [RFC7011]:
Multiple Scope Fields MAY be present in the Options Template
Record, in which case the composite scope is the combination of
the scopes. For example, if the two scopes are meteringProcessId
and templateId, the combined scope is this Template for this
Metering Process. If a different order of Scope Fields would
result in a Record having a different semantic meaning, then the
order of Scope Fields MUST be preserved by the Exporting Process.
For example, in the context of PSAMP [RFC5476], if the first scope
defines the filtering function, while the second scope defines the
sampling function, the order of the scope is important. Applying
the sampling function first, followed by the filtering function,
would lead to potentially different Data Records than applying the
filtering function first, followed by the sampling function.
If an IPFIX Mediator receives, from multiple Exporters, Template
Records with identical Information Elements, but ordered differently,
it SHOULD consider those Template Records as identical, subject to
metadata information in the associated Options Template (for example,
the Flow Key Options Template, see Section 10.2).
If an IPFIX Mediator receives, from multiple Exporters, Options
Template Records with identical and ordered Information Elements in
the Scope fields, and with identical Information Elements, but
ordered differently, in the non-Scope fields, it SHOULD consider
those Template Records as identical.
If an IPFIX Mediator receives, from multiple Exporters, Options
Template Records with identical Information Elements in the Scope
field, but ones that are ordered differently, it MUST consider those
Template Records as semantically different.
Claise, et al. Standards Track [Page 16]
RFC 7119 IPFIX MED-PROTO February 2014
4.2. Creating New Templates at an IPFIX Mediator
For other Intermediate Processes, the IPFIX Mediator generates new
(Options) Template Records as a result of the Intermediate Process.
In these cases, the IPFIX Mediator doesn't need to maintain a
Template Mapping, as it generates its own series of (Options)
Template Records. However, some special cases might still require a
Template Mapping. Consider a situation where the IPFIX Mediator
generates new (Options) Template Records based on what it receives
from the Exporter(s) based on the Intermediate Process function: for
example, an Intermediate Anonymization process that performs black-
marker anonymization [RFC6235] on certain Information Elements. In
such cases, it's important to keep the correlation between the
received (Options) Template Records and derived (Options) Template
Records in the Template Mapping. These Template Mappings would be
kept as in Section 4.1, except that the exported Template would not
be identical to the received Template.
Similar to Exporting Processes in any Exporter, an IPFIX Mediator may
use the technique for reducing redundancy in IPFIX described in
[RFC5473].
4.3. Handling Unknown Information Elements
Depending on application requirements, Mediators that do not generate
new Records SHOULD re-export values for unknown Information Elements,
for which the Mediator does not have information about Information
Element data type and semantics. However, as there may be presence
or ordering dependencies among the unknown Information Elements, the
Mediator MUST NOT omit fields from such re-exported Records or
reorder any fields within the Records.
Mediators that generate new Records, as in Section 4.2, MUST ignore
values of Information Elements they do not understand. If a Mediator
passes values of Information Elements it does not understand (for
example, when re-exporting Flow Records), it MUST pass them in the
order in which they were originally received.
In any case, Mediators handling unknown Information Elements SHOULD
log this fact, as it is likely that mediation of records containing
unknown values will have unintended consequences.
5. Preserving Original Observation Point Information
Depending on the use case, the Collector in an Exporter/IPFIX
Mediator/Collector structure (for example, tiered Mediators) may need
to receive information about the Original Observation Point(s);
Claise, et al. Standards Track [Page 17]
RFC 7119 IPFIX MED-PROTO February 2014
otherwise, it may wrongly conclude that the IPFIX Device exporting
the Flow Records, i.e., the IPFIX Mediator, directly observed the
packets that generated the Flow Records. Two new Information
Elements are introduced to address this use case:
originalExporterIPv4Address and originalExporterIPv6Address.
Practically, the Original Exporters will not be exporting these
Information Elements. Therefore, the Intermediate Process will
report the Original Observation Point(s) to the best of its
knowledge. Note that the Configuration Data Model for IPFIX and
PSAMP [RFC6728] may report the Original Exporter information out of
band.
In the IPFIX Mediator, the Observation Point(s) may be represented
by:
o A single Original Exporter (represented by the
originalExporterIPv4Address or originalExporterIPv6Address
Information Elements).
o A list of Original Exporters (represented by a list of
originalExporterIPv4Address or originalExporterIPv6Address
Information Elements).
o Any combination or list of Information Elements representing
Observation Points. For example:
* A list of Original Exporter interfaces (represented by the
originalExporterIPv4Address or originalExporterIPv6Address, the
ingressInterface, and/or egressInterface Information Elements,
respectively).
* A list of Original Exporter line card (represented by the
originalExporterIPv4Address, originalExporterIPv6Address, or
lineCardId Information Elements, respectively).
Some Information Elements characterizing the Observation Point may be
added. For example, the flowDirection Information Element specifies
the direction of the observation, and, as such, characterizes the
Observation Point.
Any combination of the above representations is possible. An example
of an Original Observation Point for an Intermediate Aggregation
Process is displayed in Figure 8.
Claise, et al. Standards Track [Page 18]
RFC 7119 IPFIX MED-PROTO February 2014
exporterIPv4Address 192.0.2.1
exporterIPv4Address 192.0.2.2,
interface ethernet 0, direction ingress
interface ethernet 1, direction ingress
interface serial 1, direction egress
interface serial 2, direction egress
exporterIPv4Address 192.0.2.3,
lineCardId 1, direction ingress
Figure 8: Complex Observation Point Definition Example
A Mediator MAY export such complex Original Observation Point
information, depending on application requirements. If such
information is exported, the Mediator MUST use [RFC6313] to do so, as
described below.
The most generic way to export the Original Observation Point is to
use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking
the previous example, the encoding in Figure 9 can be used.
Template Record 257: exporterIPv4Address
Template Record 258: exporterIPv4Address,
basicList of ingressInterface, flowDirection
Template Record 259: exporterIPv4Address, lineCardId, flowDirection
Figure 9: Complex Observation Point Definition Example: Templates
The Original Observation Point is modeled with the Data Records
corresponding to either Template Record 1, Template Record 2, or
Template Record 3 but not more than one of these ("exactlyOneOf"
semantic). This implies that the Flow was observed at exactly one of
the Observation Points reported.
When an IPFIX Mediator receives Flow Records containing the Original
Observation Point Information Element, i.e.,
originalExporterIPv4Address or originalExporterIPv6Address, the IPFIX
Mediator SHOULD NOT modify its value(s) when composing new Flow
Records in the general case. Known exceptions include anonymization
per Section 7.2.4 of [RFC6235] and an Intermediate Correlation
Process rewriting addresses across NAT. In other words, the Original
Observation Point should not be replaced with the IPFIX Mediator
Observation Point. The daisy chain of (Exporter, Observation Point)
representing the path the Flow Records took from the Exporter to the
top Collector in the Exporter/IPFIX Mediator(s)/Collector structure
model is out of the scope of this specification.
Claise, et al. Standards Track [Page 19]
RFC 7119 IPFIX MED-PROTO February 2014
The following subsections describe Information Elements for reporting
Original Exporter addresses as seen by the Collecting Process; note
they may be subject to network address translation upstream; see
[NAT-LOGGING] for more on logging in this situation.
5.1. originalExporterIPv4Address Information Element
Name: originalExporterIPv4Address
Description: The IPv4 address used by the Exporting Process on an
Original Exporter, as seen by the Collecting Process on an IPFIX
Mediator. Used to provide information about the Original
Observation Points to a downstream Collector.
Data Type: ipv4Address
ElementId: 403
5.2. originalExporterIPv6Address Information Element
Name: originalExporterIPv6Address
Description: The IPv6 address used by the Exporting Process on an
Original Exporter, as seen by the Collecting Process on an IPFIX
Mediator. Used to provide information about the Original
Observation Points to a downstream Collector.
Data Type: ipv6Address
ElementId: 404
6. Managing Observation Domain IDs
The Observation Domain ID of any IPFIX Message containing Flow
Records relevant to no particular Observation Domain, or to multiple
Observation Domains, MUST have an Observation Domain ID of 0.
IPFIX Mediators that do not change (Options) Template Records MUST
maintain a Template Mapping, as detailed in Section 4.1, to ensure
that the combination of Observation Domain IDs and Template IDs do
not collide on export.
For IPFIX Mediators that export New (Options) Template Records, as in
Section 4.2, there are two options for Observation Domain ID
management. The first and simplest of these is to completely
decouple exported Observation Domain IDs from received Observation
Claise, et al. Standards Track [Page 20]
RFC 7119 IPFIX MED-PROTO February 2014
>| | | |
|(22) ACK <a'> | | | |
|------------------------------------------------>|
Hilt, et al. Standards Track [Page 34]
RFC 6794 Session Policy Framework December 2012
| | | |(23) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(24) 200 OK |
| | | |------------------>|
| | | |(25) NOTIFY <po, pa>
| | | |------------------>|
| | | |(26) 200 OK |
| | | |<------------------|
| | | | | |
| | | | | |
B.3. Multiple Policy Servers for the UAS
UA A P A PS A PS B P B UA B
| | | | | |
| | | | | |
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
| |(2) INV <o, uri PSA> | |
| |---------------------------->| |
| | | | |(3) INV <o, uri PSA, uri PSB>
| | | | |-------->|
| | |(4) SUBSCRIBE <o, a> |
| | |<----------------------------|
| | |(5) 200 OK | |
| | |---------------------------->|
| | |(6) NOTIFY <po, pa>| |
| | |---------------------------->|
| | |(7) 200 OK | |
| | |<----------------------------|
| | | |(8) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(9) 200 OK |
| | | |------------------>|
| | | |(10) NOTIFY <po, pa>
| | | |------------------>|
| | | |(11) 200 OK |
| | | |<------------------|
| | |(12) SUBSCRIBE <o", a"> |
| | |<----------------------------|
| | |(13) 200 OK | |
| | |---------------------------->|
| | |(14) NOTIFY <po, pa> |
| | |---------------------------->|
| | |(15) 200 OK | |
| | |<----------------------------|
| | | |(16) SUBSCRIBE <o", a">
Hilt, et al. Standards Track [Page 35]
RFC 6794 Session Policy Framework December 2012
| | | |<------------------|
| | | |(17) 200 OK |
| | | |------------------>|
| | | |(18) NOTIFY <po, pa>
| | | |------------------>|
| | | |(19) 200 OK |
| | | |<------------------|
| | | | |(20) 200 OK <a">
| | | | |<--------|
| |(21) 200 OK <a"> | | |
| |<----------------------------| |
|(22) 200 OK <a"> | | | |
|<--------| | | | |
|(23) ACK | | | | |
|------------------------------------------------>|
| | | | | |
| | | | | |
Authors' Addresses
Volker Hilt
Bell Labs/Alcatel-Lucent
Lorenzstrasse 10
70435 Stuttgart
Germany
EMail: volker.hilt@bell-labs.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg
jdrosen.net
Monmouth, NJ
USA
EMail: jdrosen@jdrosen.net
Hilt, et al. Standards Track [Page 36]