100 likes | 233 Views
For Consideration by the SPEERMINT WG 65 th IETF Meeting Dallas TX March 20, 2006. Requirements for SIP-based VoIP Interconnection (BCP). draft-natale-sip-voip-requirements-00.txt Bob Natale bnatale@nextone.com. Issues needing WG consensus. Scope (BCP, Interconnection)
E N D
For Consideration by the SPEERMINT WG65th IETF MeetingDallas TXMarch 20, 2006 Requirements for SIP-based VoIP Interconnection (BCP) draft-natale-sip-voip-requirements-00.txt Bob Natale bnatale@nextone.com
Issues needing WG consensus • Scope (BCP, Interconnection) • Approaches to requirements identification • Requirements acceptance criteria • Presentation of requirements • Impact on other WG deliverables and discussions Milestone due date: March 2007 65th IETF (Dallas)
Scope:Best Current Practices document • BCP (from RFC 2026, BCP 9): • “A way to standardize practices and the results of community deliberations” • “Good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations” • “Generally only make sense for full and immediate instantiation” • “Meant to express community consensus but are arrived at more quickly than standards” • “BCPs require particular care” Generally, BCPs seem more descriptive than prescriptive in tone? 65th IETF (Dallas)
Scope:Interconnection versus Peering • Interconnection (for SPEERMINT): • Both signaling and media flows must be taken intoconsideration • Use cases that include the interaction between the application layer and lower network layers • or the dependence of specific application layer use cases on lower layers • Peering (for SPEERMINT): • The interconnection between application layer entities such as SIP servers • as opposed to interconnection at the IP networklayer Milestone deals with Interconnection 65th IETF (Dallas)
Approaches to requirements identification • Derived from other WG documents • Directly solicited from VoIP operators and administrators • Adopted/adapted from IETF and other industry requirements documents (and similar sources) • CableLabs VoIP Peering RFI • GSMA GRX/IPX Requirements • ECMA/TISPAN Next-Gen Corporate-Core Interconnection Requirements • SIP Forum IP PBX / Service Provider Interoperability • Identified via WG discussion • Other? 65th IETF (Dallas)
Candidate requirements acceptance criteria • Explicit WG consensus • Algorithmic or judgmental basis? • Deployment weight • The “de facto” factor: • Number of deployments • Perceived VSP/ITAD influence • Fairness • Innovation • Verifiability • Universality (non-Locality) • External mandates • Other SDOs, Government regulation • Other? Broader than the usual IETF baseline of “necessary for interoperability”? 65th IETF (Dallas)
Presentation of requirements • Grouping • By peering entity type? • VSPs versus ITADs? • Access, Core, Interconnect, Enterprise, Federation • Is Originating versus Terminating relevant? • draft-bhatia-sip-peering-00.txt • By criticality? • Mandatory, Recommended, Optional • By functional category? • App, Signaling, Media, Traffic Eng, O&M, Security • draft-khan-ip-serv-peer-arch-00.txt • Ordering: • By importance? • By operational phases? • By network architecture locus? Some form of multi-dimensionalmatrix format willbe required. Complexity versuscompleteness andconsistency. 65th IETF (Dallas)
Requirements Cataloguedraft-natale-sip-voip-requirements-00.txt • 3.1 0.0000 General Requirements • 3.8 0.2100 Regulatory Requirements • 3.29 1.0000 Network Architecture • 3.46 2.0000 Operations Management • 3.55 2.2000 Network and Systems Management • 3.61 2.3000 Session Management • 3.62 2.7000 International Operations Support • 3.63 2.8000 Integration with existing NOC/OSS/BSS Functions • 3.64 2.9000 Legacy Peering Agreements • 3.65 3.0000 Partitioning • 3.69 4.0000 Accounting • 3.78 4.3000 Billing • 3.79 5.0000 SLAs • 3.85 5.3000 Quality of Service (QoS) • 3.90 6.0000 Security • 3.95 6.2000 Topology Hiding • 3.98 6.4100 Authentication • 3.99 6.4200 Encryption • 3.100 6.5000 Privacy Requirements • 3.101 6.5100 Identity Requirements • 3.102 6.5200 Subscriber Data Protection Sample subset(out of 103 candidates)forillustration purposes 65th IETF (Dallas)
M Mandatory R Recommended O Optional X Not Applicable One possible presentation formatColoring for illustration purposes only BCP would use ASCII text table 65th IETF (Dallas)
Impact on other WG deliverables and discussions • Should requirements drive other deliverables? • Should requirements devolve from other deliverables? • Should requirements and other deliverables take shape interactively? • I.e., both of the above...? Jul 2006 Submit SPEERMINT terminology I-D (Informational) Sep 2006 Submit I-D defining the SPEERMINT routing architecture (Informational) Dec 2006 Submit I-D defining the message flows associated with the SPEERMINT routing architecture (Informational) Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP) Mar 2007 Submit I-D on the minimum set of requirements for SIP-based VoIP interconnection (BCP) Jul 2007 Submit I-D specifying the use of strong identities in session peering and supporting the establishment and exchange of trust between domains (BCP) Jul 2007 Submit I-D(s) on use cases (BCP) 65th IETF (Dallas)