datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Liaison Statement: IETF PCN Working Group Response to Liaison Statement TD 151 (NGN-GSI) (Q.5/11) from ITU-T Study Group 11

Submission Date: 2008-09-25
From: IETF PCN WG (Steven Blake)
To: ITU-T/Study Group 11 (Tina Tsou)
Cc:IETF PCN Working Group
Lars Eggert
Magnus Westerlund
Monique Morrow
Response Contact: Steven Blake
Scott Bradner
Technical Contact: IETF PCN Working Group
Purpose: In response
Attachments: (none)
Body:
To: ITU-T Study Group 11

Thank you for your liaison statement from your Geneva meeting on your
intent to incorporate PCN into the RACF framework.

For your information, the fifth draft of the PCN Architecture document
has completed working group last call, and we expect that the sixth
draft (incorporating edits in response to comments from the last call)
will be submitted for IESG review and IETF last call prior to the next
IETF plenary in November.  This draft is available at:
http://tools.ietf.org/html/draft-ietf-pcn-architecture-06.

Subsequent to our last liaison statement, the PCN working group has
achieved consensus to advance a 2-state PCN encoding proposal for
Proposed Standard, although the specific proposal is still under
development.  Consensus was also achieved to allow a 3-state PCN
encoding proposal to be advanced for Experimental status, although
again no specific proposal has been finalized.  We note that your
attached draft Q.PCNApp "Enhancement of resource and admission control
protocols to use pre-congestion notification (PCN)" appears to assume
that a 3-state PCN encoding mechanism is available, and we wish to
advise you that there is no consensus to standardize a 3-state PCN
encoding mechanism at this time.

In addition, we wish to inform you that the PCN working group has not
made progress in defining a protocol for conveying pre-congestion
information from an egress node to an ingress node (corresponding to
the Rc interface defined in <Draft Q.PCNApp>).

We note that <Draft Q.PCNApp> discusses the transport of network
topology information from the TRC-PE function to an egress node, to
assist the egress node in associating a received packet with the
ingress node via which that packet entered the network.  We believe
that the use of topology information as a means to determine the
ingress node of a particular packet will only work in certain
constrained network topologies.  We suggest that one alternative
approach would be to define an interface from the PD-PE function to the
egress node, to convey packet classification state for admitted flows.

We would like to ask for clarification on the role and operation of the
Rp interface in <Draft Q.PCNApp>.  It is not clear from the text
whether commands are issued by the centralized TRC-PE function towards
the TRC-FE function, and if so, what is the defined behavior of these
commands.


Thank you,

Steven Blake and Scott Bradner, PCN working group co-chairs