Network Interoperability Specification

Network Interoperability
Specification
Version 1.0
Document Management
Document Identification
File Name
Version
Document Owner
WIRE Reference
Version
Date Released
UFF_Network_Interoperability_Document.DOCX
1.0
Engineering Manager
Change Notice
Remarks
A
0.1
Updated dual POI operation
Updated POI definition to support BIDI optics and exclude
RSP bundling
0.2
30-Mar-12
0.3
5-Apr-12
0.4
30-Apr-12
Added Chorus tie cable attributes appendix
Modified process for allocation of fibres on Chorus tie cable
to MOFDF
0.5
18-May-12
Included the Chorus UFF abbreviations
0.6
8 June-12
Updated appendix 1 with NPL
0.7
20-June-12
0.8
8-August-12
0.9
15-August-12
0.9A
30 August-12
0.9B
13 Sept-12
0.9C
13 Nov-12
0.9D
13 March-13
1.0
27 July 2014
Added specification for Tie Cables
Updated section 5.2.1 with additional procedural details for
provisioning an external tie cable.
Updated DHCP Option 82 details in section 7.1 and added a
new section 7.2 describing the PPPOE IA functionality
Added section 7.3 to define the ServiceID. Modified 7.1 to
reference the ServiceID and include a UFF suffix in the
RemoteID.
Updated WAN and NPL diagrams. Added sections about the
separation of services and the consideration for highest
availability services.
Minor updates from CFH review and general tidy up.
Introduced section on Class of Service handling.
Minor updates from CFH. Added flow diagrams to DHCP
and PPPoE definitions.
Added that the DCHP Option 82 circuit ID will comply with
the service descriptions.
Corrected Wanganui 2 letter abbreviation. Option 82
remote ID uses the PIID. Changed HOP to HOC.
Page 2 of 29
Contents
1. Background ............................................................................................................................. 5
1.1 Objective of this document ................................................................................................. 5
1.1 Document Lifecycle ............................................................................................................. 5
2. High Level Layer 1 Network Model ..................................................................................... 5
2.1 Direct Fibre Access Service ............................................................................................... 6
2.2 Backhaul Access.................................................................................................................. 6
3. High Level Layer 2 Network Model ..................................................................................... 6
3.1 Hamilton, Te Awamutu, Cambridge and Tokoroa ........................................................... 7
3.2 Tauranga ............................................................................................................................... 8
3.3 New Plymouth and Hawera ................................................................................................ 9
3.4 Wanganui ............................................................................................................................ 10
4. Handover Port Technical Specification ............................................................................. 11
4.1 Point of Interconnection .................................................................................................... 11
4.2 Separation of Services ...................................................................................................... 11
4.3 Highest Availability Services ............................................................................................ 11
4.4 Protected Handover Port .................................................................................................. 11
4.5 Handover Port Configurations.......................................................................................... 11
4.5.1
Single HOP connection – No LAG implemented ................................. 12
4.5.2
Single HOP connection – LAG implemented ....................................... 12
4.5.3
Dual HOP connection – MC-LAG implemented................................... 13
4.5.4
Dual HOP connection –LAG optional .................................................... 14
5. Backhaul................................................................................................................................ 14
5.1 UFF MOFDF to Chorus MOFDF Tie Cable ................................................................... 15
5.1.1
Installation Process .................................................................................. 15
5.2 External Tie Cable (External to building & direct from Chorus Co-location) ............. 15
5.2.1
Installation Process .................................................................................. 15
5.2.2
Additional Services on existing cable .................................................... 16
5.3 Direct Fibre Access Service ............................................................................................. 16
5.3.1
Installation Process .................................................................................. 16
5.4 Inter CO Interconnection Service .................................................................................... 16
5.4.1
Installation Process .................................................................................. 16
6. Process to get Connected .................................................................................................. 16
6.1 Products Available ............................................................................................................. 16
6.2 How to Order ...................................................................................................................... 17
6.3 Getting an Update of the Connection Process .............................................................. 17
6.4 Assistance Available ......................................................................................................... 17
7. Design Details ...................................................................................................................... 17
7.1 S-VLAN and C-VLAN Allocation ...................................................................................... 17
7.2 TR-069 Support.................................................................................................................. 18
7.3 Class of Service ................................................................................................................. 18
7.3.1
BS2 CoS handling .................................................................................... 18
7.3.2
BS3 CoS Handling ................................................................................... 18
Page 3 of 29
7.3.3
BS3A CoS Handling................................................................................. 18
7.3.4
BS4 CoS Handling ................................................................................... 19
7.3.5
ATA Voice CoS Handling ........................................................................ 19
7.3.6
Multicast CoS Handling ........................................................................... 19
7.4 DHCP V4 Option 82 .......................................................................................................... 19
7.4.1
CircuitID (Sub option 01) ......................................................................... 20
7.4.2
RemoteID (Sub option 02) ...................................................................... 21
7.5 PPPoE V4 Intermediate Agent ........................................................................................ 21
7.6 DHCP V6 Option 18 and 37 ............................................................................................. 22
7.7 PPPoE V6 Intermediate Agent ........................................................................................ 23
7.8 ServiceID................................................................................. Error! Bookmark not defined.
7.9 OAM ..................................................................................................................................... 25
8. Integrated Test Facility ........................................................................................................ 25
Appendix 1.
Chorus Tie Cable Details ............................................................................. 27
Appendix 2.
Tie Cable Specifications .............................................................................. 28
Page 4 of 29
1. Background
Ultrafast Fibre has been selected by Crown Fibre Holdings as the Local Fibre Company
to deploy a fibre optic network in the following urban areas:









Hamilton
Cambridge
Te Awamutu
Tokoroa
Tauranga
Mt Maunganui
New Plymouth
Whanganui
Hawera
The project will deliver high speed broadband to over 160,000 commercial and
residential customers which comprise 13.7% of the New Zealand urban population.
The Network is available on an open access wholesale basis, to provide OSI layer 1
and Layer 2 Ethernet services to Access Seekers to provide further wholesale or retail
services to End Users. The network is ‘access agnostic’ to ensure that there is no
discrimination between Service Providers.
1.1 Objective of this document
The document provides the minimum technical specifications, procedures and other
relevant activities required to be met by such third parties in order to achieve
interoperability with the UFF network.
If there is any inconsistency between this document and the relevant Service
Description and Operations Manual documentation, then the terms, specifications
and provisions in those documents prevail.
1.1 Document Lifecycle
Any changes to this document will be subject to the Change Procedure. Clause
1.1(b)(v) of the NIPA provides that, once the DFP is complete, this document will be
an Annexure to the NIPA - and therefore form part of the NIPA (refer clause 1.1(a) of
the NIPA). The Change Procedure governs changes to the NIPA.
2. High Level Layer 1 Network Model
The demarcation points for the Direct Fibre product are authoritatively defined in the
Direct Fibre Product Description.
All UFF Central Offices are located within Chorus/Telecom facilities.
For convenience they are repeated in this document as follows:
Page 5 of 29
2.1 Direct Fibre Access Service
The DFAS is terminated on the line side IODF located within the Central Exchange.
2.2 Backhaul Access
The same backhaul as installed for backhauling Bitstream services can be used to
backhaul DFAS services.
Further details on how to install a backhaul service are provided in section 5.
3. High Level Layer 2 Network Model
The high level logical network design is provided in the following figures.
In each location 10 Gbps and 1 Gbps fibre ports are available for Service Provider
connections (refer section 4 for further details).
The numbers of OLT and Access switches that are depicted in the following sections
are informative only.
The locations of the POIs and central exchanges are available at
http://www.ultrafastfibre.co.nz/rsps/publications-resources-and-tools .
Page 6 of 29
3.1 Hamilton, Te Awamutu, Cambridge and Tokoroa
Figure 1 shows the design for the Hamilton, (including Te Awamutu and Cambridge)
and Tokoroa Candidate Areas.
The Te Awamutu, Cambridge and Tokoroa areas are accessible from the Hamilton
POIs and Service Providers do not need to connect separately to those areas.
A Service Provider connecting to either POI will have Bitstream access to all End Users
irrespective of which POI they connect to. Further details on connection methods are
outlined in section 4.
OLT GPON
MA5600T
EAS
CX600-X8
DWDM
OSN1800
Hamilton
POI 1 EAS
Access P2P
Switch S9306
Hamilton
POI 2 EAS
Hamilton
CO 1
10G SM
10Km
Hamilton
CO 2
10G Logical
Through
DWDM
10G SM
40Km
Cambridge
CO
1G Uplink
20 x 1G
16 x 10G
20 x 1G
10G Uplink
16 x 10G
2
Te Awamutu
CO
RSP
DWDM
Tokoroa CO
Figure 1: High Level Design for Hamilton, Te Awamutu, Cambridge
and Tokoroa
The service to Tokoroa’s CO has no physically redundant backhaul link whereas
Cambridge and Te Awamutu are connected via a fibre ring that provides physical
redundancy.
Page 7 of 29
Inter CO
3.2 Tauranga
Figure 2 shows the design for the Tauranga Candidate area which also includes Mt
Maunganui.
A Service Provider connecting to either POI will have Bitstream access to all End Users
irrespective of which POI they connect to. Further details on connection methods are
outlined in section 4.
OLT GPON
MA5600T
EAS
CX600-X8
Access P2P
Switch S9306
10G SM
10Km
Tauranga CO 1
(TGW)
Tauranga
POI 2 EAS
Tauranga
POI 1 EAS
2
1G Uplink
Tauranga CO 2
(TGE)
10G Uplink
2
20 x 1G
20 x 1G
16 x 10G
16 x 10G
RSP
Figure 2: High Level Design for Tauranga
Page 8 of 29
Inter-CO
3.3 New Plymouth and Hawera
Figure 3 shows the design for New Plymouth and Hawera.
The Hawera End Users are accessible from New Plymouth and there is no POI
available in Hawera. The backhaul from Hawera has no physical redundancy available.
New Plymouth
CO
OLT GPON
MA5600T
EAS
CX600-X8
DWDM
OSN1800
Access P2P
Switch S9306
10G SM
10Km
New Plymouth
POI EAS
DWDM
10G Logical
Through
DWDM
10 x 10G
40 x 1G
40 x 1G
1G Uplink
10 x 10G
10G Uplink
10G LAG
RSP
Hawera CO
Figure 3: High Level Design for New Plymouth and Hawera
Both EAS are located within the same Central Office in adjacent racks. Resilience can
be obtained through the same protected Handover Port configurations as for those
areas where the EASs are in different Central Offices.
Page 9 of 29
3.4 Wanganui
Figure 4 shows the design for Whanganui and consists of a dual EAS configuration
similar to New Plymouth.
Wanganui
CO
OLT GPON
MA5600T
EAS
CX600-X8
Access P2P
Switch S9306
10G Primary
10G Backup
10G LAG
Wanganui
POI EAS1
Wanganui
POI EAS2
1G Uplink
10G Uplink
40 x 1G
16 x 10G
40 x 1G
16 x 10G
RSP
Figure 4: High Level Design for Wanganui
Both EAS are located within the same Central Office in adjacent racks. Resilience can
be obtained through the same protected HOP configurations as for those areas where
the EASs are in different Central Offices.
Page 10 of 29
4. Handover Connection Technical Specification
A Handover Connection (HOC) is available in 1 Gbps or 10 Gbps optical interfaces. No
copper based interfaces are available.
4.1 Point of Interconnection
The CO demarcation is the connection on the UFF MOFDF within the Point of
Interconnection. Several physical handover ports may be used at the POI depending
on capacity or service requirements. A Service Provider may purchase multiple HOCs if
they wish to have separation of services or similar.
Details of the physical characteristics can be found in the Bitstream product
descriptions.
4.2 Separation of Services
Where the Service Provider uses an aggregator for backhaul, it is recommended that
each Service Provider uses Handover Ports that are not shared with other Service
Providers. This will allow each Service Provider to utilise a greater VLAN range on the
handover port.
At the Service Providers discretion, all Bitstream services can be provided through a
common handover connection. UFF does not require separate handover connections
for a BS2 versus a BS4 etc. service.
4.3 Highest Availability Services
Where the Service Provider is providing a service that requires a high availability
service, they should consider implementing a protected HOC.
For example, a Service Provider may wish to use a protected HOC for their Voice
services to ensure that emergency calls can be made by the End Users.
4.4 Protected Handover Connection
A protected HOC facility is available to Service Providers through implementing LAG
between the Service Provider’s edge device and the UFF network.
The HOP will be terminated on a CX-600 Metro Services Platform which operates as
the Ethernet Aggregation Switch. Detailed Interoperability testing will need to be
carried out for connection to other vendors’ equipment.
LAG comprising primary and secondary groups is supported and Services Providers are
to advise UFF of their requirements. Comprehensive testing within UFF’s Integrated
Test Facility in Auckland must be undertaken prior to implementing on a production
network, to ensure inter-vendor compatibility.
4.5 Handover Connection Configurations
Where two POIs are located within the same area, or two EASs are located within the
same Central Office, the Service Provider only needs to connect to one POI to gain
Page 11 of 29
access to all Bitstream connected End Users within that area. The choice of which POI
the Service Provide connects to, is the Service Provider’s choice.
4.5.1 Single HOP connection – No LAG implemented
This is the most common installation configuration.
The single HOC is always extended to the second EAS using Eth-trunk to service all
Bitstream End Users as shown in Figure 5.
For clarity only a single HOC is shown but this configuration can be used for multiple
independent HOCs.
RSP PE
RSP
Network
UFF
Network
EAS 1
Eth-trunk
EAS 2
Figure 5: Default HOP connection
When a failure occurs on the RSP to UFF link, then all customers in the candidate area
will lose service.
4.5.2 Single HOC connection – LAG implemented
When LAG is implemented between the RSP and the POI, it will be configured as 1:1
mode but this may change to load sharing as the links traffic grows.
Page 12 of 29
RSP PE
RSP
Network
Eth-trunk
UFF
Network
EAS 1
EAS 2
Eth-trunk
Figure 6: HOP implemented using LAG
Failure of one leg of the LAG will cause all traffic to flow through the other link with
packet loss only occurring during the switch over. If the remaining link’s handover
point has insufficient capacity then packet loss will occur and packets will be
forwarded based on their CoS. It is the Service Provider’s responsibility to manage the
capacity of the LAG link.
4.5.3 Dual HOC connection – Primary and Secondary
groups implemented
RSP PE
Primary
and
Secondary
LAG
RSP
Network
UFF
Network
EAS 1
Eth-trunk
EAS 2
Figure 7: HOP implemented using MC-LAG
Failure of one leg of the LAG will cause all traffic to flow through the other link with
only packet loss occurring during the switch over.
It is the Service Provider’s responsibility to manage the capacity of the LAG link.
Page 13 of 29
4.5.4 Dual HOC connection –LAG optional
Where the Service Provider connects via two separate PEs to separate POIs, the
Service Provider may utilize both links simultaneously and select their PEs
primary/secondary state using VRRP or similar.
RSP PE
RSP
Network
RSP PE
Optional
Eth-trunk
Optional
Eth-trunk
UFF
Network
EAS 1
Eth-trunk
EAS 2
Figure 8: Dual independent HOPs
Failure of either RSP PE to EAS will cause all traffic to flow through the other link with
only packet loss occurring during the switch over.
5. Backhaul
A Service Provider can obtain a backhaul service using any mixture of the following
methods:
 Obtain a dark fibre or layer 2 service from a third party provider (external tie
cable) that has facilities outside of the UFF co-location area. These facilities
may still be within the Telecom/Chorus facility.
 Obtain a dark fibre service from UFF through the Direct Fibre Access Service
(DFAS) to the Services Provider’s POP or a third party back hauler’s POP
within the UFF coverage area.
 Interconnect to a Third party provider’s equipment located in UFF’s colocation space.
The first two options do not require the Service Provider to purchase any UFF colocation space.
All UFF central offices are contained within Telecom or Chorus facilities and therefore
provisioning of these links must comply with Telecom or Chorus requirements as well
as the UFF requirements for running cables within those premises.
Page 14 of 29
5.1 UFF MOFDF to Chorus MOFDF Tie Cable
UFF have installed tie cables between the UFF MOFDF and the Chorus MOFDF that
can be utilized by the Service provider. This may be used when the Service Provider or
the third party backhaul provider has taken a co-location service directly with Chorus.
5.1.1 Installation Process
The Service Provider or Third party backhaul provider is responsible for requesting the
installation of a tie cable between their co-location rack and the Chorus MOFDF.
The Service Provider shall specify to Chorus the UFF MOFDF as the termination point
of the interconnection. A list of the UFF MOFDFs is provided in Appendix 1. Chorus
will engineer the connection between the Service Provider’s cabinet and the MOFDF
to ensure that there is connectivity all the way through. This is particularly important
when there are multiple tie cables for Chorus to select from.
UFF will allocate fibres on the tie cable to the UFF MOFDF and advise the Service
Provider of the selected fibres.
UFF, on receipt of a handover service request directly from the Service Provider, will
patch from the UFF MOFDF (tie cable to Chorus MOFDF) to the handover port on the
UFF equipment.
5.2 External Tie Cable (External to building & direct from
Chorus Co-location)
Where the Service Provider has not taken any Chorus co-location service they may
install an external tie cable directly to the UFF MOFDF. This service can also be used
when a tie cable is to be installed directly between the Service Provider’s Co-location
footprint and the UFF MOFDF.
This second case is regarded as an external tie cable because it is external to the UFF
co-location area compared to an internal tie cable which runs from a Service
provider’s co-location footprint within the UFF area to the UFF MOFDF.
This cable will bypass the Chorus MOFDF and therefore is only suitable for direct
connection to the UFF MOFDF.
5.2.1 Installation Process
The Service Provider shall request from the Service Desk, permission to install an
External Tie Cable into a UFF MOFDF. This request shall include details of which
MOFDF the tie cable will be terminated into and the size (number of fibres) of the
cable. The Service Desk will allocate termination ports within the MOFDF and advise
this allocation back to the Service Provider.
Once permission to terminate into the UFF MOFDF has been received, the Service
Provider shall make a request directly to Chorus for the installation of the external tie
cable. The cable shall conform to the pig cable specifications defined in Appendix 2.
Page 15 of 29
When the Tie Cable RFS date is advised from Chorus to the Service Provider, the
Service Provider shall advise the Service Desk via email of the RFS date and the Service
Desk will arrange for the Tie Cable to be patched into the UFF MOFDF.
5.2.2 Additional Services on existing cable
Where an existing tie cable is going to be used for backhauling Bitstream services, the
Service Provider shall place an order for a Handover Connection to UFF including
details on the cable number and the fibre core allocations. UFF, on receipt of a
handover service request, will patch from the UFF MOFDF to the handover port on
the UFF equipment.
5.3 Direct Fibre Access Service
Where a Service Provider has their Point of Presence within the Central Office Serving
Area, the Service Provider may order a Direct Fibre Access Service from UFF.
The DFAS circuit will be built as a standard DFAS circuit and no special allowance will
be made for the fact that it is being used for a backhaul service.
5.3.1 Installation Process
The Service Provider would place a service order with UFF for the provision of a Direct
Fibre Access Service from the POI to the Service Provider’s POP. This would be
terminated within the Service Provider’s MOFDF as mutually agreed.
UFF, on receipt of a handover port request directly from the Service Provider, will
patch from the UFF L-IOFDF to the handover port on the UFF equipment.
5.4 Inter CO Interconnection Service
This service provides a dark fibre interconnection between Central Offices and POIs
that can be used by Service Providers to backhaul service from either their equipment
located in the remote Central Office or from a Direct Fibre Access Service in the
remote Central Office.
Refer to the Inter CO interconnection service product Service Description.
5.4.1 Installation Process
The Service Provider shall order the service through the UFF ordering portal. The
order shall include orders for the fibre patching service at both ends, to connect the
inter-CO service to the destination service such as a HOP, tie cable or similar.
6. Process to get Connected
6.1 Products Available
The backhaul products available are specified in the Central Office and POI Colocation service description and the Direct Fibre Access Service service description.
Page 16 of 29
The Service provider will need to order a UFB handover connection at each POI that
they wish to connect to, to provide Bitstream services.
6.2 How to Order
All these products are ordered through the UFF service portal.
If the Service Provider does not have access to the UFF service portal, these initial
services can be requested via their UFF account manager.
6.3 Getting an Update of the Connection Process
Refer to the Reference Offer Operations Manual for the options available.
6.4 Assistance Available
UFF operates a 24 x 7 service desk that can provide assistance to a Service Provider to
obtain connectivity.
It is recommended that requests for assistance be made during business hours as
wider support options will be available.
7. Design Details
This section discusses specific design details.
7.1 S-VLAN and C-VLAN Allocation
The traffic presented at the HOC shall be either:
 802.1ad VLAN (SVID, CVID) (ethertype x88a8); or
 Double tagged QnQ (ethertype x9100).
It is recommended that the HOC be presented as 802.1ad to allow for the Service
Provider to take advantage of future enhancements such as colour aware Class of
Service traffic.
The traffic at the UNI shall be presented (defined on a per UNI basis) as one of the
following:
 Tagged Ethernet Frames (802.1q single tag);
 Priority tagged Ethernet frames (CVID=0);
 Untagged, native Ethernet frames.
Depending on the Bitstream product, the C-VID will be transported transparently or
will be translated prior to the UNI. The C-VID translation will allow a Service Provider
to present the same VLAN to their supplied Residential Gateway for ease of
configuration while maintaining separate C-VIDs on the HOP.
The S-VID and C-VID will be allocated by UFF at the time of provisioning of a new End
User or the provisioning of an additional service to an existing End User.
Page 17 of 29
Further details of the VLAN schema will be provided in a revision of this document in
Q1 2013.
7.2 TR-069 Support
TR-069 is not currently supported for access to UFF’s equipment. Service Providers are
not restricted from using it to manage their own equipment.
7.3 Class of Service
All Bitstream services support traffic management based on the Class of Service
markings.
The CoS is identified using the three bits of the 802.1q frame which allows for eight
levels to be defined. The current implementation uses only two CoS which are:


High priority has an 802.1q priority tag of 4. (subject to
change by the TCF)
Low priority has an 802.1q priority tag of 0.
The priority is determined from the SVLAN markings. Traffic from the End Users UNI
has the CVLAN priority copied to the SVLAN priority when the SVLAN is added to the
traffic.
7.3.1 BS2 CoS handling
All SVLAN packets ingressing through the HOC not marked as 4 will be remarked as 0.
In the DS direction, the CVLAN markings are ignored.
In the US direction, the CVLAN markings not marked as 4 will be remarked as 0.
Untagged packets presented at the UNI will have the CVLAN marked as low priority
and SVLAN as low priority.
7.3.2 BS3 CoS Handling
All SVLAN packets ingressing through the HOC will be marked as 4 and treated as high
priority. CVLAN priority markings will be ignored.
Untagged packets presented at the UNI will be marked with CVLAN as high priority
and SVLAN as high priority.
7.3.3 BS3A CoS Handling
All SVLAN packets ingressing through the HOC not marked as 0 will be remarked as 4.
Untagged packets presented at the UNI will be marked with CVLAN as low priority and
SVLAN as low priority.
Page 18 of 29
7.3.4 BS4 CoS Handling
All SVLAN packets ingressing through the HOC will be marked as 4 and treated as high
priority. CVLAN priority markings will be ignored.
Untagged packets presented at the UNI will be marked with CVLAN as high priority
and SVLAN as high priority.
7.3.5 ATA Voice CoS Handling
All SVLAN packets ingressing through the HOP marked as 4 is accepted. All other
traffic is discarded.
As the UNI-V is an analogue interface all traffic will be CoS marked by the ATA as high
priority (4).
7.3.6 Multicast CoS Handling
All SVLAN packets ingressing through the HOP marked as 4 is accepted. All other
traffic is discarded.
Untagged traffic is not accepted.
7.4 DHCP V4 Option 82
The Option 82 field, which is the DHCP relay agent option field, carries information
about End User access. The Option 82 field is appended to a packet by the snoopingenabled DHCP relay agents or switches. The DHCP server does not need to parse the
Option 82 field but must keep the Option 82 field unchanged and return it in a
DHCPREPLY packet. After the snooping-enabled device receives the DHCPREPLY
packet, and if the option 82 information matches what it added, the Option 82 field is
removed from the packet.
The message flows are shown in Figure 9.
Page 19 of 29
Figure 9: DHCP message flows
The information provided in the option 82 tag is defined in the following sections.
7.4.1 CircuitID (Sub option 01)
The circuit ID will be inserted as specified in the Bitstream Service Descriptions,
namely if this feature is requested TR-101 information will be embedded in DHCP or
PPPOE traffic.
In the sub option 01 (circuitID), the packet will formatted as “anid xpon
frame/slot/subslot/port:ontid.gemport.vlanid” where
anid
The system name allocated by UFF to identify the network
element. E.g. UFFHMOLTHMW001
xpon
A static identifier.
Frame The frame number. Will always be set to zero (0).
slot
The slot number within the OLT
subslot Will be set to zero (0)
port
The physical port number within the OLT slot
ontid
An id of the ONT on the physical port.
gemport The gemport configured during the provisioning process
vlanid The cvid used for the service. Note this may be different to
the cvid used on the Handover Port.
Note that for a BS2 service, the gemport number will be different for the Class of
Service = 4 and Class of Service = 0 traffic that have the same S-VLAN and C-VLAN.
Page 20 of 29
The circuitID may change during the lifecycle of a connection where there is grooming
of the ONT’s network connection.
The circuitID is not notified to the Service Provider during the provisioning process.
7.4.2 RemoteID (Sub option 02)
Unless agreed otherwise during the RSP on-boarding process, Sub option 02
(remoteID) will contain a concatenation of “UFF” and the non-optional part of the
ServiceID. Further details of the ServiceID are provided in 7.6 and an example of a
remoteID would be UFFTCLHM00007890.
An example of the information provided is shown in Figure 10 with the Circuit ID
information highlighted.
Figure 10: Example DHCP V4 option 82 information
Service Providers should advise UFF during the product on-boarding process if they
wish to have DHCP V4 Option 82 enabled by default.
The format of the remoteID is currently being discussed by the Telecommunications
Carriers Forum (TCF) and is subject to change.
7.5 PPPoE V4 Intermediate Agent
The PPPOE IA operates in a similar manner to the DHCP option 82 and if enabled, will
return the circuit ID and Remote ID specified in the DHCP option 82 tag.
An example of the message flows is shown in Figure 11 and an example of the
information provided is shown in Figure 12.
Page 21 of 29
Figure 11: PPPoE Intermediate Agent Message Flows
Figure 12: Example PPPOE V4 Intermediate Agent information
The PPPOE IA and the DHCP option 82 can be enabled simultaneously for the same
End User.
Service Providers should advise UFF during the product on-boarding process if they
wish to have PPPOE V4 IA enabled as the default.
7.6 DHCP V6 Option 18 and 37
DHCP V6 support can be enabled on request from an Access Seeker.
The DHCP V6 option 18 and option 37 is implemented similarly to DHCP V4 with the
following functionality mapping between V4 and V6:
Page 22 of 29


DHCP V6 option 18 is functionally similar to DHCP V4 Option 18 Circuit ID;
DHCP V6 option 37 is functionally similar to DHCP V4 Option 18 Remote ID.
An example of the message that would be received by the Access Seeker is provided
in Figure 13.
Figure 13: Example DHCP V6 option 18 & 37 information
Service Providers should advise UFF during the product on-boarding process if they
wish to have DHCP V6 Option 18/37 enabled by default.
If the DHCP V6 relay agent is enabled, it will provide both options information.
Enabling only one option is not supported
7.7 PPPoE V6 Intermediate Agent
PPPoE V6 is similar to PPPoE V4 Intermediate agent functionality.
An example of the message that would be received by the Access Seeker is provided
in Figure 14.
Page 23 of 29
Figure 14: Example PPPOE V6 Intermediate Agent information
Service Providers should advise UFF during the product on-boarding process if they
wish to have PPPOE V6 IA enabled as the default.
7.8 Product Instance ID
During the provisioning of a Bitstream process a PIID will be advised to the Service
Provider by the UFF Service Desk.
The PIID uniquely defines a service. A separate PIID is also provided to define
Handover Port.
The PIID will remain static until the service is cancelled and is irrespective of speed
changes etc. If the End User changes the technology, that is, change from a GPON to
point-to-point service, then the PIID will change. A summary of activities and the
effect on the PIID ID is provided in Table 1.
Activity
Effect on Product Instance ID
1. New Connect
new PIID
2. Relinquish
no PIID
3. Move Address
new PIID at new address
4. Transfer (old RSP to new
RSP)
5. Change Profile (to same
tech family)
old PIID at old address (then
RQ)
new PIID for new RSP
old PIID for old RSP (then RQ
and LSP event)
same PIID
Page 24 of 29
6. Change Profile (to different
tech family )
new PIID on new service
old service id for old service
(then RQ)
same PIID
7. Change ONT (same type)
8. Change OLT (same type)
/OLT port /OLT card
9. Change HOP
same PIID
10. Change POI
same PIID
11. Change secondary SP to
Primary SP
12. Add/change/remove SLA
same PIID
same PIID
same PIID
Table 1: Impact on Product Instance ID from various activities
The Product Instance ID is defined as UFFrrraa0000000000 where
 rrr is a three letter Service Provider character string that is
defined during the on-boarding process.
 aa is a two character string that identifies the POI area. Valid
POI areas are:
o HM
Hamilton including Te Awamutu, Cambridge
and Tokoroa.
o TG
Tauranga including Mt Maunganui.
o NP
New Plymouth including Hawera.
o WA
Wanganui.
 00000000 is an eight digit sequence number.
An example of a PIID is UFFTCLHM00007890
7.9 OAM
OAM services are not currently available but our vendor road map shows equipment
becoming OAM capable in 2015.
8. Integrated Test Facility
An Integrated Test Facility (ITF) is available for Service Providers to utilise, that
enables testing and product development without affecting operational systems. It
enables Service Providers to develop, test and modify their Telecommunications
Services to work on the Network.
Page 25 of 29
The ITF contains two EASs, an OLT, Point to Point aggregation switch and firewall. The
configuration is similar to Tauranga (refer Figure 2) but with only one OLT and the
addition of premises equipment such as GPON ONTs and P2P ONUs.
Service Provider Connection to the ITF can be through either:
1. The Service Provider temporarily installing equipment in the ITF to undertake
the testing, or;
2. The establishment of a layer 3 tunnel between the ITF and the Service
Providers POP over the public Internet. The ITF has a 10 Mbps Internet link
(National traffic only) to facilitate this.
If the Service Provider uses the public Internet to interconnect, then stress testing and
SLA conformance for an end to end test is not recommended due to the variances
that the public Internet will introduce.
The ITF also contains a Spirent test centre that can be made available. UFF
Contractors are available to operate and define tests.
Please refer to the UFF document “ITF Management Process” for further information.
Page 26 of 29
Appendix 1. Chorus Tie Cable Details
The details of the tie cables from the Chorus IODF to the UFF MOFDF are detailed
within this appendix. There are typically two diverse route cables available and
terminated on diverse UFF MOFDFs.
The MOFDF locations within each Telecom/Chorus exchange can be referred to using
the following abbreviations. When ordering tie cable allocations through Chorus,
these abbreviations must be used.
Name
Telecom/ Chorus
CO abbreviation
HTC / HN
MOFDF “A”
MOFDF “B”
Hamilton West
UFF
Abbreviation
HMW
Bay: UFBH/1A009
UFBH/B1-B4
(fed from Chorus
HTC L1 MOFDF HN
L871 Row 1A rack
7 cable shelf 1
trays 1 – 4)
Hamilton East
HME
CLE
Cambridge
Te Awamutu
Tokoroa
New Plymouth
CAM
TAW
TOK
NPL
CB
TAW
TOB
NU
Hawera
Wanganui
HAW
WAN
HW
WG
Tauranga West
TGW
TG
Tauranga East
TGE
MMN
UFCLE/1A008
(Chorus cable
UFCD/B1-B2 F124)
UFXCB/1A008
UFTAW/1A008
UFTOB/1A008
UFXNU/1A008
I466
(fed from Chorus
MOFDF bay 6
drawer Q465)
UFXHW/1A008
UFXWG/1A008
(Fed by Chorus
cable WG206 from
L.425 and
terminated into
splice tray L.101
located in the
bottom of the UFF
cabinet)
UFXTG/1A008
(fed from Chorus
Row 31B bay 7 TG
Q503)
UFMMN/1A008
(fed from Row
23B Bay 10 L319
F1-24 using cable
MMN26 ACX972)
Bay: UFBH/1B009
UFBH/B5-B8
(fed from Chorus
HTC L5 MOFDF
HN L873 (FOG
HN_F001xlsN)
Row 43 Bay 9B
shelf 1 trays 1 – 4)
UFCLE/1B008
(Chorus cable
UFCD/B3-B4 F124)
UFXCB/1B008
UFTAW/1B008
UFTOB/1B008
UFXNU/1B008
I468
(fed from Chorus
MOFDF bay 3
drawer Q467)
UFXHW/1B008
UFXWG/1B008
(Fed by Chorus
cable WG207
from L. 428 and
terminated into
splice tray L.102
located in the
bottom of the UFF
cabinet)
UFXTG/1B008
(fed from Chorus
Row 31B, bay 2 TG
Q505)
UFMMN/1B008
(fed from Row
23B Bay 7 L318
F1-24 using cable
MMN26 ACY971)
Table 2: Designations of UFF MOFDFs
Page 27 of 29
Appendix 2. Tie Cable Specifications
The tie cables that are terminating within a UFF MOFDF shall comply with the
following specifications.
The specification refers to the termination of the cable within the MOFDF. The
Service Provider’s end of the cable can be pre-terminated in connectors or be
fusion spliced at the Service Provider’s discretion.
UFF prefer 24F and 48F tie cables which must be terminated in LC/APC connectors
at the UFF MOFDF end. The construction details are shown in Figure 15 and Figure
16.
Figure 15: External Tie cable construction details (24 fibre)
Page 28 of 29
Figure 16: External Tie cable construction details (48 fibre)
The cables are available from Tyco Electronics in Auckland. Example stock
numbers are:
Part Number Detail
Description
TC01149
PIGCB SM LCA D24 08M-UFF
24 fibre, 8 m
7-1700914-2 PIGCB SM LCA 48F 20M UFF
48 fibre 20m
8-1700914-2 PIGCB SM LCA 48F 30M UFF
48 fibre 30m
Table 3: Tyco Part Numbers for approved pig cables
Page 29 of 29

Download Report