Liaison statement
IETF PCN Working Group Response to Liaison Statement TD 151 (NGN-GSI) (Q.5/11) from ITU-T Study Group 11
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2008-09-25 |
From Group | pcn |
From Contact | Steven Blake |
To Group | ITU-T-SG-11 |
To Contacts | Tina Tsou <tena@huawei.com> |
Cc | IETF PCN Working Group <pcn@ietf.org> Lars Eggert <lars.eggert@nokia.com> Magnus Westerlund <magnus.westerlund@ericsson.com> Monique Morrow <mmorrow@cisco.com> |
Response Contact | Steven Blake <sblake@extremenetworks.com> Scott Bradner <sob@harvard.edu> |
Technical Contact | IETF PCN Working Group <pcn@ietf.org> |
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 |