ATIS 0800048-2011 Test Cases for Network Attachment Service Provider Discovery and Attachment and Services Discovery.pdf

1、 ATIS-0800048 TEST CASES FOR NETWORK ATTACHMENT, SERVICE PROVIDER DISCOVERY AND ATTACHMENT, AND SERVICES DISCOVERY ATIS is the leading technical planning and standards development organization committed to the rapid development of ATIS is the leading technical planning and standards development orga

2、nization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 200 companies actively formulate standards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wir

3、eless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP

4、Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a m

5、ember of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (ANSI). For more information, please visit . Notice of Disclaimer Stage 3, 2002.414 3GPP TS 33.203, 3G Security; Access security for IP-based services, 2002.415 3GPP TS 3

6、3.220, Generic Authentication Architecture (GAA); Generic bootstrap architecture, 2004.43 NETWORK CONFIGURATION The architecture for network configuration testing is defined within ATIS-0800047 1 and shown in Figure 1. This figure is derived from the ATIS IIF IPTV Functional Architecture by eliminat

7、ing functions that are not involved with the attachment scenarios. Some functions that are commonly included in IP or IMS networks and are involved with attachment scenarios are not shown in Figure 1 i.e., a Domain Name Service (DNS) server. These items are identified in the scenarios where they pla

8、y a role. Transport & Access NetworksTransport FunctionsNACFE0Md, E5E3iCore IMSP-CSCApplication FunctionsS-CSC I-CSCSUPVideoHeadendMdT1RCMSAAADNGH4H6H5H1SP&S Disc. FunctionsKeyNot in scope at this timeIn scopeA0S2S4ARFIPTV ApplicationE1 (XML)AUPA4ITFDNGITFFigure 1: Scenario 1 Physical Architecture 4

9、This document is available from the Third Generation Partnership Project (3GPP) at . ATIS-0800048 4 4 SCENARIO 1 TEST CASES: ATTACHMENT 4.1 Scenario 1a: DNG Attachment Dynamic Network Gateway (DNG) network attachment refers to the activities associated with the DNG establishing Layer 3 connectivity

10、to an IP network. Once the network attachment activities have been completed, the DNG will be capable of transmitting and receiving IP packets and establishing a management session with a Remote Configuration and Management Server (RCMS). Subsequently, the RCMS is used to provision the DNG with acce

11、ss-network specific parameters. The test cases in this section are to verify the protocol usage, processes, and message content for DNG network attachment. 4.1.1 Test Setup Transport & Access NetworksTransport FunctionsNACFT1RCMSAAADNGH4H1KeyNot in scope at this timeIn scopeARFDNGFigure 2: Scenario

12、1a Basic Configuration 4.1.1.1 Resources Required The following components are required for this scenario: Transport Network Elements (Access Node, Edge Router). One NACF (DHCP server, AAA function, RCMS). One DNG. One DNS server (not shown). 4.1.1.2 Test Pre-conditions Network configuration is as p

13、er section 4.1.2. DNS server recognizes the RCMS. 4.1.2 Test Cases 4.1.2.1 Test Case 1a1: IP Address of RCMS in DHCP Offer “siaddr” Field 1. Attach DNG to network and establish layer 1 and layer 2 connectivity (out of scope). 2. DNG issues a DHCP DISCOVER message. 3. DNG learns the following in the

14、DHCP OFFER: ATIS-0800048 5 o IP address of DNG in the “yiaddr” field. o DNG network subnet mask in the subnet mask Option 1. o DNS Server IP address(es) in the DNS Option 6. o Default gateway IP address in the Default Router Option 3. o IP Address of the RCMS in the “siaddr” field. 4. The DNG constr

15、ucts the URL of the RCMS as described in ATIS-0800017 2, section 3.2. 5. The DHCP protocol sequence completes with the standard DHCP REQUEST and DHCP ACK messages. 6. The DNG is able to achieve connectivity with the RCMS. 4.1.2.2 Test Case 1a2: URL of RCMS in DHCP Offer Option 43 1. Attach DNG to ne

16、twork and establish layer 1 and layer 2 connectivity (out of scope). 2. DNG issues a DHCP DISCOVER message. 3. DNG learns the following in the DHCP OFFER: o IP address of DNG in the “yiaddr” field. o DNG network subnet mask in the subnet mask Option 1. o DNS Server IP address(es) in the DNS Option 6

17、. o Default gateway IP address in the Default Router Option 3. o “siaddr”=0.0.0.0. o URL of the RCMS in Option 43. 4. The DHCP protocol sequence completes with the standard DHCP REQUEST and DHCP ACK messages. 5. The DNG is able to achieve connectivity with the RCMS. 4.1.2.3 Test Case 1a3: FQDN of RC

18、MS in DHCP Offer Option 43 1. Attach DNG to network and establish layer 1 and layer 2 connectivity (out of scope). 2. DNG issues a DHCP DISCOVER message. 3. DNG learns the following in the DHCP OFFER: o IP address of DNG in the “yiaddr” field. o DNG network subnet mask in the subnet mask Option 1. o

19、 DNS Server IP address(es) in the DNS Option 6. o Default gateway IP address in the Default Router Option 3. o “siaddr”=0.0.0.0. o Fully Qualified Domain Name (FQDN) of the RCMS in Option 43. 4. The DNG constructs the URL of the RCMS as described in ATIS-0800017 2, section 3.2. 5. The DHCP protocol

20、sequence completes with the standard DHCP REQUEST and DHCP ACK messages. 6. The DNG is able to achieve connectivity with the RCMS. 4.1.2.4 Test Case 1a4: FQDN or RCMS in DHCP Offer Option 15 1. Attach DNG to network and establish layer 1 and layer 2 connectivity (out of scope). ATIS-0800048 6 2. DNG

21、 issues a DHCP DISCOVER message. 3. DNG learns the following in the DHCP OFFER: o IP address of DNG in the “yiaddr” field. o DNG network subnet mask in the subnet mask Option 1. o DNS Server IP address(es) in the DNS Option 6. o Default gateway IP address in the Default Router Option 3. o “siaddr”=0

22、.0.0.0. o FQDN of the RCMS in Option 15 as extended by the ATIS IIF in ATIS-0800017 2, Appendix A. 4. The DNG constructs the URL of the RCMS as described in ATIS-0800017 2, section 3.2. 5. The DHCP protocol sequence completes with the standard DHCP REQUEST and DHCP ACK messages. 6. The DNG is able t

23、o achieve connectivity with the RCMS. 4.1.2.5 Test Case 1a5: URL of RCMS is Manually Configured 1. Attach DNG to network and establish layer 1 and layer 2 connectivity (out of scope). 2. DNG issues a DHCP DISCOVER message. 3. DNG learns the following in the DHCP OFFER: o IP address of DNG in the “yi

24、addr” field. o DNG network subnet mask in the subnet mask Option 1. o DNS Server IP address(es) in the DNS Option 6. o Default gateway IP address in the Default Router Option 3. o “siaddr”=0.0.0.0. o FQDN of RCMS is not provided. 4. The DNG is manually configured with the URL of the RCMS. 5. The DHC

25、P protocol sequence completes with the standard DHCP REQUEST and DHCP ACK messages. 6. The DNG is able to achieve connectivity with the RCMS. 4.1.3 Observable Results 4.1.3.1 Pass/Fail criteria The DNG achieves connectivity with the RCMS in each test case. 4.1.3.2 Message Flow The DNG attachment mes

26、sage flow is shown below. ATIS-0800048 7 Figure 3: Scenario 1a DNG Attachment Flows 4.1.3.3 Trace Capture The main focus of this test case is the interaction between the DNG and the NACF (DHCP Server). The traces of the messages exchanged on the H1 interface should be captured during the testing and

27、 validated against the test case descriptions. 4.1.3.4 Known Issues None. 4.2 Scenario 1b: ITF Attachment ITF device network attachment refers to activities associated with the ITF device establishing Layer 3 connectivity to an IP network and obtaining network configuration information data. Once th

28、e network attachment activities have been completed, the ITF will be capable of transmitting and receiving IP packets and establishing a management session with an RCMS. The test cases in this scenario verify the protocol usage, processes, and message content for ITF network attachment. ATIS-0800048

29、 8 4.2.1 Test Setup Transport & Access NetworksTransport FunctionsNACFT1RCMSAAADNGH4H6H5H1KeyNot in scope at this timeIn scopeARFITFDNGITFFigure 4: Scenario 1b Configuration 4.2.1.1 Resources Required The following components are required for this scenario: Transport Network Elements (Access Node, E

30、dge Router). One NACF (DHCP server, AAA Function, RCMS). One DNG. One ITF. One DNS server (not shown). 4.2.1.2 Test Pre-conditions DNG is attached to the network and knows the address of the RCMS. 4.2.2 Test Cases 4.2.2.1 Test Case 1b1 Procedure 1. Attach ITF to DNG and establish layer 1 and layer 2

31、 connectivity (out of scope). 2. ITF issues a DHCP DISCOVER message with the mandatory Options including the vendor class identifier Option 60. ATIS-0800048 9 3. ITF learns the following in the DHCP OFFER: o IP address of ITF in the “yiaddr” field. o ITF network subnet mask in the subnet mask Option

32、 1. o DNS Server IP address(es) in the DNS Option 6. o Default gateway IP address in the Default Router Option 3. o IP Address of the RCMS in the “siaddr” field. 4. The ITF constructs the URL of the RCMS as described in ATIS-0800017 2, section 6.1. 5. The DHCP protocol sequence completes with the st

33、andard DHCP REQUEST and DHCP ACK messages. 6. The ITF is able to achieve connectivity with the RCMS. 4.2.3 Observable Results 4.2.3.1 Pass/Fail criteria The ITF achieves connectivity with the RCMS. 4.2.3.2 Message Flow The ITF attachment message flow is shown below. Figure 5: Scenario 1b ITF Attachm

34、ent Flows 4.2.3.3 Trace Capture The main focus of this test case is the interaction between the ITF and the DNG. The traces of the messages exchanged on the H5 interface should be captured during the testing and validated against the test case descriptions. ATIS-0800048 10 4.2.4 Known Issues None. 4

35、.3 Scenario 1c: Non-IMS Service Provider Discovery and Attachment Service Provider Discovery is the process by which an ITF becomes aware of the available IPTV Service Provider(s), and learns the means of attaching to a Service Provider. The list of one or more Service Provider(s) available to the s

36、ubscriber is offered by the Network Provider (NP). The information will be represented in the manner appropriate for each service discovery method. Six Service Provider Discovery methods are defined in ATIS-0800017 1: five for non-IMS IPTV networks and one for IMS-based IPTV networks. The discovery

37、methods differ in the number of steps to be performed by an ITF to obtain the Service Providers information. A method can obtain the Service Provider discovery information directly in a single step, or indirectly by first obtaining a pointer to the information and then obtaining the information. Eac

38、h Service Provider discovery method concludes with the ITF obtaining metadata for each Service Provider Discovery is specified in ATIS-0800022 6, section 8.1 Once the ITF device has discovered the available Service Providers and selected a Service Provider, the next step is Service Provider (SP) aut

39、hentication and attachment. The end result of SP authentication and attachment is that the ITF device has obtained metadata for Service Provider authentication as specified in ATIS-0800022 6, section 9.1.1, and metadata for Service Provider attachment as specified in ATIS-0800022 6, section 9.2.1. A

40、TIS-0800048 11 4.3.1 Test Setup Transport & Access NetworksTransport FunctionsNACFE0Md, E5Application FunctionsVideoHeadendMdT1RCMSAAADNGH4H6H5H1SP&S Disc. FunctionsKeyNot in scope at this timeIn scopeARFIPTV ApplicationE1 (XML)AUPA4ITFDNGITFFigure 6: Scenario 1c Configuration 4.3.1.1 Resource Requi

41、rements The following components are required for this scenario: Transport Network Elements (Access Node, Edge Router). One NACF (DHCP server, AAA Function, RCMS). One DNG. One ITF. One SP&SD Server. One source of multicast atis-iif-service-locator.xml file (Video Headend). One IPTV Application Serv

42、er include authentication server function. One DNS server (not shown). One Client Authentication Server (not shown). 4.3.1.2 Test Pre-conditions 1. DNG and ITF are attached to the network and configured. 4.3.2 Test Cases The following figure shows a sequence of steps followed between when the ITF at

43、taches to the network and gets configured (step 1) and attachment to a service (step 5). After the ITF attaches to the network, ATIS-0800048 12 it follows a path through the figure from top to bottom in a series of steps with several alternative methods for each step. The test cases for non-IMS Serv

44、ice Provider Discovery are identified as 1c1, 1c2, 1c3, and 1c4 in step 2. The test cases for ITF attachment to a service provider are identified as 1c5 and 1c6 in step 3. 1-Network Attachment2-Service Provider DiscoveryFor IMS Services based on DHCP Option 120For Non-IMS Services3-Attach to SP and

45、Query Specific Servers4-Services Discovery and Selection5-Service Attachment and OperationNot in scope of this specification documentPhase/Outcome Method / ProcedureUsing pre-configured informationPer ATIS-0800009Remote Management of Devices in the Consumer Domain for IPTV ServicesThe ITF gets servi

46、ces data such as EPG and SIThe ITF attaches to a Service Provider and queries specific serversThe ITF learns the means for attaching to a Service ProviderThe ITF gets its IP address and the IP address of the RCMS, performs remote configuration procedure, and attaches to the networkViaTFTP(1c1)Via BB

47、FTR-069(1c2)Via known multicast stream (1c3)IMS registration (1d1)and authentication (1d2)No action required when SP equals NPOptional discovery of “Service Discovery Application Server”Network Attachment via DHCP Procedure (1bx)Remote Configuration ProcedureAuthentication and Authorization (1c4)Ser

48、vice Specific MethodMulticast Push (1e1)WS Pull(1e2)Attachment via SIP Notification Package(s) (1d3)Web Services based transactions (1c5)Provided through authentication responseFigure 7: Phases of ITF Device Attachment and Initialization 4.3.2.1 Test Case 1c1: Service Provider Discovery using Downlo

49、ad from the Network Provider Domain Method 1. The ITF obtains the location of the Network Providers Service Provider Discovery Server: o Preconfigured or manually-configured FQDN, resolved by DNS lookup. o Preconfigured or manually-configured IP address. o FQDN via DHCP Option 66 (TFTP Server Name) during ITF network attachment and resolved by DNS lookup. 2. ITF retrieves the file atis-iifservice-provider-locator.xml from the Service Provider Discovery Server. This file is an XML document