ITU-T J 362-2006 IPCablecom2 control point discovery (Study Group 9)《IPCablecom2控制点发现研究组9》.pdf

《ITU-T J 362-2006 IPCablecom2 control point discovery (Study Group 9)《IPCablecom2控制点发现研究组9》.pdf》由会员分享，可在线阅读，更多相关《ITU-T J 362-2006 IPCablecom2 control point discovery (Study Group 9)《IPCablecom2控制点发现研究组9》.pdf（54页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T J.362TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2006) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom IPCablecom2 control point discovery ITU-T Recommendation J.362 ITU-T Rec. J.362

2、 (11/2006) i ITU-T Recommendation J.362 IPCablecom2 control point discovery Summary This Recommendation defines an IP-based protocol that can be used to discover a control point for a given IP address. The control point is the place where QoS operations, lawful intercept (LI) content tapping operati

3、ons, or other operations may be performed. Source ITU-T Recommendation J.362 was approved on 29 November 2006 by ITU-T Study Group 9 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. J.362 (11/2006) FOREWORD The International Telecommunication Union (ITU) is the United Nations

4、specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications

5、 on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid

6、 down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunicat

7、ion administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandato

8、ry provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws att

9、ention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or othe

10、rs outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent

11、 the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2007 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. J.362 (11/2006) i

12、ii CONTENTS Page 1 Scope 1 2 References. 1 3 Definitions 1 4 Abbreviations and acronyms 1 5 Conventions 2 6 Technical overview. 2 6.1 Assumptions . 3 7 Interface description . 3 7.1 Network-based control point discovery application. 4 7.2 NLS-TL header parameters 5 7.3 CPD request 5 7.4 CPD response

13、 . 6 7.5 Error responses . 7 8 Procedures 7 8.1 Requestor 7 8.2 Control point. 8 9 Security considerations. 9 Annex A Network Layer Signaling: Transport Layer 10 Annex B QoS requirements 44 Appendix I Open issues 45 Bibliography. 46 ITU-T Rec. J.362 (11/2006) 1 ITU-T Recommendation J.362 IPCablecom2

14、 control point discovery 1 Scope This Recommendation defines an IP-based protocol that can be used to discover a control point for a given IP address. The control point is the place where QoS operations, lawful intercept (LI) content tapping operations, or other operations may be performed. 2 Refere

15、nces None. 3 Definitions This Recommendation defines the following terms: 3.1 control point: Within the context of this Recommendation, control point refers to a point in the network that can be used to apply a function for a media flow that flows through that point. Functions described here are: Qo

16、S (IPCablecom multimedia b-ITU-T J.179 or IPCablecom DQoS b-ITU-T J.163). Replication, encapsulation and transmission for the purposes of LI content tapping. 3.2 control point discovery: The act of discovering information (IP address, protocol) concerning a control point in order to allow a requesto

17、r to apply a specific controlling function. 3.3 requestor: The requestor in this context is the controller that wishes to control the control point and hence needs to discover the necessary information to do so. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and ac

18、ronyms: CMS Call Management Server CMTS Cable Modem Termination System COPS Common Open Policy Service CPD Control Point Discovery CR Control Relationship DF Delivery Function DNS Domain Name Service DQoS Dynamic Quality of Service ICE Interactive Connectivity Establishment IP Internet Protocol LI L

19、awful Intercept MIB Management Information Base NAT Network Address Translation NE Network Element 2 ITU-T Rec. J.362 (11/2006) NLS Network Layer Signalling NLS-TL Network Layer Signalling Transport Layer PS Policy Server QoS Quality of Service SDP Session Description Protocol STUN Simple Traversal

20、of UDP through NAT TURN Traversal Using Relay NAT UDP User Datagram Protocol 5 Conventions Throughout this Recommendation, the words that are used to define the significance of particular requirements are capitalized. These words are: “MUST“ This word means that the item is an absolute requirement o

21、f this Recommendation. “MUST NOT“ This phrase means that the item is an absolute prohibition of this Recommendation. “SHOULD“ This word means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weig

22、hed before choosing a different course. “SHOULD NOT“ This phrase means that there may exist valid reasons in particular circumstances when the listed behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviou

23、r described with this label. “MAY“ This word means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 6 Technical overview The general approac

24、h for control point discovery is illustrated by the reference model in Figure 6-1. A requestor that knows the IP address of the media endpoint sends a control point discovery (CPD) message toward that endpoint (reference point pkt-qos-2). A control point in the path between the requestor and the end

25、point recognizes the CPD message and responds back with the IP address to use for the particular application. The requestor can then make the necessary request for that application. Figure 6-1 Control point discovery architecture ITU-T Rec. J.362 (11/2006) 3 In addition to supplying the IP address t

26、o use, the CPD response indicates the protocol to use and can optionally supply which subnet the destination address of the media endpoint is contained within. Some of the components that need to make use of CPD are as follows: IPCablecom call management server (CMS), in order to determine the IP ad

27、dress of the CMTS for making a DQoS request. IPCablecom multimedia policy server (PS), in order to determine the IP address of the CMTS for requesting IPCablecom multimedia b-ITU-T J.179. IPCablecom delivery function (DF), in order to determine the IP address of the CMTS or aggregation device for pe

28、rforming a lawful intercept content tap of the media stream. CPD is not limited to QoS and LI. It may be used for other applications as well. The CMS, PS and DF in the above examples need to determine which CMTS or aggregation device (the IP addresses they need to control) will handle the media stre

29、am based on the information these components have (the IP address of the endpoint which was obtained via SDP). Several approaches have been suggested, as follows: 1) Provisioning of subnet versus control point information within each device. 2) Provisioning within DNS b-IETF RFC 4183. 3) Collecting

30、subnet information over the COPS DQoS or IPCablecom multimedia interface. Approaches 1 and 2 above are provisioning solutions and as such present operational difficulties. Approach 3 is an application-specific solution that uses a policy management protocol for an unintended purpose, and cannot be r

31、eused to address other requirements (e.g., LI). The approach described here is a generic approach that can be used for all three of the above applications and other applications as well. 6.1 Assumptions The following basic assumptions are used in defining the interface specification in clause 7: For

32、 the majority of cases, the media endpoint is single-homed behind the control point (i.e., the media route will go through a specific CMTS, media gateway or aggregation device). For possible exceptions to this assumption, the requestor can be provisioned with alternates (i.e., when the requestor rec

33、eives a CPD response with the IP address of one control point, it is able to determine the IP address of control points for alternative media paths for that media endpoint). For some applications (e.g., LI), it is important that the CPD message does not reach a media endpoint outside the providers n

34、etwork. The assumption is that ACL mechanisms will be in place to drop CPD packets at edge devices that do not support the CPD protocol. 7 Interface description CPD uses the network layer signalling protocol (NLS). As illustrated in Figure 7-1, NLS consists of an application layer that sits on top o

35、f an NLS transport layer (NLS-TL) protocol as defined in Annex A. 4 ITU-T Rec. J.362 (11/2006) Figure 7-1 NLS protocol One such application is the network-based control point discovery application defined in this Recommendation. 7.1 Network-based control point discovery application The application p

36、ayload format within NLS consists of an NLS type, length, value (TLV) that consists of a 16-bit application ID followed by a payload that is opaque to the NLS transport layer. Per clause 14.2 of Annex A, the application ID for the control point discovery (CPD) application is “1“. The CPD message for

37、mat is illustrated in Figure 7-2. For the network-based CPD application, a CPD messages consist of: A 4-bit version field. The 4-bit version field is set to “0“ for the version of the CPD protocol described in this Recommendation. A 12-bit CPD message type. Only two CPD message types are defined: CP

38、D request: CPD message type = 1. CPD response: CPD message type = 2. A 16-bit control relationship (CR) type. The CR TYPE identifies the type of control relationship. These values may be provisioned. The requestor MUST set the CR TYPE to one of the following values: CR TYPE = 1: Lawful intercept con

39、tent tap. CR TYPE = 2: DQoS. CR TYPE = 3: IPCablecom multimedia. A 16-bit control relationship ID (CR ID). A 32-bit transaction ID. CPD message contents for the particular CPD message type. 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 Application ID Version CPD message typ

40、e CR TYPE CR ID Transaction ID CPD message contents Figure 7-2 CPD message format The CR TYPE and CR ID uniquely define a specific control relationship between a group of controllers and the network elements (NEs) they control. If more than one NE along a CPD request path can respond to a CPD messag

41、e with a given CR TYPE, they would have different CR IDs based on the provisioned CR ID value within the NE. ITU-T Rec. J.362 (11/2006) 5 It MUST be possible to provision the control point with a CR ID. The requestor MUST set the CR TYPE to one of the following values: For CR TYPE = 1 (lawful interc

42、ept): CR ID = 1: CMTS. CR ID = 2: Aggregation router or switch in front of a CMTS. CR ID = 3: Aggregation router or switch in front of media services (e.g., voice-mail). CR ID = 4: Media gateway. CR ID = 5: Conference server. CR ID = 6: Other. For CR TYPE = 2 (DQoS) and CR TYPE = 3 (IPCablecom multi

43、media): CR ID = 1: Default value. The transaction ID is used by the requestor to relate a CPD response to a given CPD request. It is up to the requestor to pick transaction IDs that do not repeat within a time-frame that would prevent this correlation from occurring. 7.2 NLS-TL header parameters For

44、 all network-based CPD messages, the requestor and control point MUST set the NLS-TL flags as follows: HOP-BY-HOP = 0; BUILD-ROUTE = 0; TEARDOWN = 0; BIDIRECTIONAL = 0. The use of the AX_CHALLENGE and AX_RESPONSE flags are described separately in clause 9. The requestor MUST set the flow-ID to a ran

45、dom number and the same value MUST be used by the control point in the response. 7.2.1 NLS-TL TLVs The following NLS-TL TLVs are not used: NAT_ADDRESS; TIMEOUT; IPV4_HOP; IPV6_HOP. 7.3 CPD request The CPD request message contents simply consists of a 32-bit number that contains some request control

46、flags. 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 Flags Reserved Figure 7-3 CPD request message contents 6 ITU-T Rec. J.362 (11/2006) The contents of the CPD request message are illustrated in Figure 7-3. The fields are as follows: Flag definitions: 0x01: Subnet informat

47、ion request. 0x02: Forward if not supported. 0x04-0x80: Reserved and set to “0“. The remaining 24 bits of the message contents are reserved and set to “0“. If the “forward if not supported“ flag is set to “1“, and the control relationship consisting of the CR TYPE and CR ID is not supported on this

48、device, the control point MUST attempt to continue to forward the CPD packet towards its destination. Otherwise it MUST respond with a response code “control relationship not supported“ as indicated in clause 7.5. This mechanism is helpful in several cases. A couple of examples are as follows: This

49、allows for an LI to have a different control point to that used for QoS. So, for example, LI could be done on an aggregation device in front of the CMTS with the control point for QoS being on the CMTS. A QoS CPD request would be sent with the “forward if not supported“ flag set to “1“, while an LI CPD request would normally have this flag set to “0“. There may be two control points along the path that are of the same CR TYPE but different CR IDs. Again, if the