Internet Architecture Board


August 2006

ITU NGN Liaison Report

Scott Brim
28 August 2006

  • ITU-T held an NGN-GSI (global standards initiative) just after the last IETF. SG13 finished a lot of NGN Recommendations at this meeting, essentially concluding “NGN Release 1”. Most are undergoing the “alternative” approval process but “NGN requirements” and “NGN security requirements” are undergoing “traditional” approval, which means they are being evaluated by the member states.
    • Supplement 1 to Y.2000 Series Recommendations – NGN Release 1 Scope, TD 193 (PLEN)
    • Y.2201 (formerly Y.NGN-R1-Reqts) – NGN Release 1 Requirements, TD 223 (PLEN)
    • Y.2012 (formerly Y.NGN-FRA) – Functional Requirements and Architecture, TD 194 (PLEN)
    • Y.2021 (formerly Y.NGN-IFN) – IMS for NGN, TD 219 (PLEN)
    • Y.2031 (formerly Y.NGN-PIEA) – PSTN/ISDN emulation architecture, TD 220 (PLEN)
    • Y.2111 (formerly Y.RACF) – Requirements and architecture for Resource and admission control in NGN, TD 205 (PLEN)
    • Y.1714 (formerly Y.17fw) – MPLS management framework, TD 198 (PLEN)
    • Y.2271 (formerly Y.csem) – General requirements for call server based PSDN/ISDN emulation, TD 203 (PLEN)
    • Y.2261 (formerly Y.piev) – PSTN/ISDN evolution to NGN, TD 201 (PLEN)
    • Y.2701 (formerly Y.NGN-security) – Security Requirements for NGN Release 1, TD 206 (PLEN)
    • Y.1315 (formerly Y.vpn-qos) – Support for VPN services – Framework and Characteristics, TD 226 (PLEN)
    • Y.term – Terms and Definitions for NGN, TD 192 (PLEN)
    • Supplement to Y-series Recommendations – Session/Border Control Functions, TD 221 (PLEN)
    • Y.CACPriority – Admission Control Priority Levels in NGN, TD 208 (PLEN)

    Those SG13 Questions involved in producing NGN Release 1 will now be looking at Release 2 in addition to continuing their non-Release-1 work.

  • SG13 Q4 is still discussing requirements for flow-state-aware forwarding, which assumes an IPv6 hop-by-hop header option. They have decided to send a liaison to the IETF, which should appear just about now. The originators of this work say they will bring it to the IETF in San Diego.
  • There is general agreement on using IETF terminology when talking about IETF concepts related to PWE3 pseudowires. The purpose is to make it easier for implementers and customers to understand the concepts. There are some edge cases that are still being worked out.
  • FYI ITU-T Director Zhao, who will be leaving his post in a few months, gave a few parting words. In particular:1.5 Corporations with other SDOs

    We have to continue our efforts to strengthen our cooperation with SDOs. WSC, GSC, “Informal Forum Summit”, etc. should be continued. We have to encourage industry forum to stay close or move inside ITU-T. We have to facilitate effective cooperation with SDOs.

    It is not possible, and neither necessary, for ITU to go everywhere. However, it would be good if any SDO in the market think about ITU, or invite ITU to join them to launch projects. It would be very bad if the SDOs try to keep distance from ITU, or even worse, to work against ITU. (I am talking about the general tendency, but not an individual case.)

    1.6 WTSAs

    I would like to see a way that WTSA will attract interests of SDOs, Fora/Consortia and others who are concerned on the ICT standardization. It would be better if WTSAs become a summit of the global family of standardization, but not only by the ITU-T Members only.