Passive Optical LAN Training: Module 4: Services Description

Passive Optical LAN Training: Module 4: Services Description
3HV01415AAAHUNZZA v August 2016

Presentation Outline Section 1: VLAN & VPLS/VVPLS Structure (OLT)
Section 2: VLANs & Bridge Ports (ONT) Section 3: Quality of Service Section 4: FTT Desktop Service Section 5: High Speed Internet Service Section 6: Security Access Control Service Section 7: Digital Signage Service Section 8: Surveillance Service Section 9: WiFi Access Point Service Section 10: Public Announcement/Intercom Service Section 11: POL Services: Modes of Operation Section 12: Filters Section 13: Lab Exercise

1 VLANs and VVPLS/VPLS Structure (OLT)

Logical Architecture: Ihub (Module 2 recap)
Ihub is the logical network facing switch Comprises of network uplink and LT card downlink ‘ports’ Operates in a split/non split horizon per service as required This is the logical component of the NT controller card(s), the FANT-F. This can be considered as a multi-port switch of which the 4 or 8 LT line cards (FX-4, FX-8) are connected via 4/8 backplane switch ports, and also includes the NT-A and NT-B uplink ports. Therefore the switch comprises of 4/8 LT ports and a maximum of 5 electrical/optical ports per NT card, making a total of 14/18 logical switch ports the Ihub can terminate in the POL solution offering. By default, the Ihub logical ports operate by default as a split horizon group. All 4/8 LT ports are ‘leaf’ ports and cannot (by default) forward to each other and can only forward to a network uplink (‘root’) port; one of the NNI uplink (LAG) ports on the ISAM. Therefore any service VLAN configured between the customers serviced via the LT cards PON ports will forward traffic to/from the network ports, not the LT ports, known as intelligent (residential) Bridging, (i-bridge). Therefore a VLAN configured for a service hosting a chassis worth of customers will forward to/from the network port NNI interface, even if traffic is destined for another adjacent ONT hosted customer. This is essential for services that have a hub/spoke and client/server relationship architecture and is also essential for the likes of billing and lawful intercept. This baseline functionality can be changed by configuration to disable this split horizon behaviour on a per (V)VPLS/VLAN (i.e., per service) basis which is required for some service concepts.

Logical Architecture: Ihub (Module 2 recap)
A POL Service is defined via a VPLS (Virtual Private LAN Service, aka ‘VLAN’) The VPLS is mapped to the LAG uplink and all the LT cards To transport user traffic across the NT board, we configure one of the following: A: A VLAN Virtual Private LAN Service (VVPLS) instance per VLAN in the Ihub, providing 802.1Q framing via the network NNI uplink. A singular Residential Bridge VLAN is connected via all LT cards to this VVPLS. B: A VLAN Virtual Private LAN Service (VPLS) instance VLAN in the Ihub, providing 802.1Q framing via the network NNI uplink with multiple ONT UNI VLANs connected as ‘spokes’ via the LT cards. The (V)VPLS contains Service Access Points (SAPs) which are Layer 2 interfaces within the NT board. In case of ‘option A’ above, the VVPLS will contain 9 SAPs (FX-8) or 5 SAPs (FX-4). Using the example of a VLAN tag value of 100, one SAP will always be the uplink LAG and a VLAN (e.g. lag-1:100) and the other SAPs will be the LT facing interfaces connecting to the backplane and a VLAN (e.g. LT Line Card 1, lt:1/1/1:100 i.e., rack, shelf, line card, VLAN 100). This is built in the Ihub via CLI. Each POL service will have a dedicated v-VPLS instance that is built to the uplink network ports (NT-A/NT-B hosted LAG) and all LT Line Cards. For ‘Option B’, the LT SAPs will be many different VLAN ID values connecting the ‘spoke’ VLANs from each desktop data service UNI. This (V)VPLS instance will have the following features enabled, disabled or common across all instances: 1: The Network Ports (NT-A and NT-B SFP ports) are defined as a LAG Group. This will be the ‘network’ ingress/egress SAP (Service Access Point). 2: The LT backplane ports LT1, LT2 -> LT4 or LT8 (FX-4 or FX-8) are the leaf SAP’s. 3: An Ingress QoS profile will be applied per service. This will forward the traffic in an appropriate queue dependent on the service. 4: MAC address limit = ‘4000’. This will limit the MAC learning database per service (VPLS or VVPLS VLAN) in the Ihub to ‘4000’ entries. This is more than sufficient and provides protection to other services if one service ever experienced a DoS attack via an FDB table ‘thrashing’ preventing the global Ihub limit from being breached.

Logical Architecture: Ihub (continued)
SAP = VLAN-ID VLAN LT-1 The LAG Uplink VVPLS SAP -> lt:1/1/1:x SAP -> lt:1/1/4:x Above is another logical view of a VVPLS instance. Substitute in the ‘x’ parameter with the VLAN-ID used in the LT Card VLAN described in the later slides. IHUB VLAN LT-4 SAP -> nt-a:lag-1:x

The POL services (except for desktop data and HSI that have a VVPLS and VPLS option) have one VLAN/VVPLS per service. Any VLAN tag value can be used, examples as follows: FTT Desktop (voice, but not data): VVPLS/VLAN 101 VOIP/PBX: VVPLS/VLAN 200 Surveillance: VVPLS/VLAN 400 WiFi Access Point: VVPLS/VLAN 500 Security Access Control: VVPLS/VLAN 600 Public Announcement / Intercom: VVPLS/VLAN 700 Digital Signage: VVPLS/VLAN 800 GPON Remote Console Access (Management): VVPLS 4093 Example below in the 5571 PCC is a the Security Access Control Service: All services (except desktop data and HSI which have both options) will be provided via a Residential i-Bridge VLAN and a VVPLS. A singular 802.1Q VLAN per POL service within the 7360 FX POLT will provide connectivity and specific features enabled/disabled per service. The Channel Partner/Customer will have the flexibility to allocate their own VVPLS/VLAN numbering schemas as their network dictates. The VLAN allocations above are examples only. Therefore the Channel Partner/Customer will declare the VVPLS, allocate a VLAN number, assign the LAG and LT ports to the service, set the maximum MAC address limit for the VVPLS and assign the QoS queuing profile.

The POL services for FTT desktop data & HSI have a VPLS per service (i.e., not a VVPLS), and one Cross-connect VLAN per UNI (User Port). Example is ‘HSI data’, and ‘FTT-desktop (data)’. A contiguous range of VLAN ID tag values is recommended for allocation. Examples as follows: FTT Desktop (data): VPLS 100/VLAN 3000, 3001, 3002, 3003, etc for UNI ports 1,2,3,4,5 etc. HSI Data: VPLS 300/VLAN 3200, 3201, 3202, 3203 etc for HSI UNI ports 1,2,3,4 etc 5571 PCC example below is that of ‘FTT_DATA_VPLS’ service type: Data Services requiring User2user communication in conjunction with a reasonably prevalent use case of an ‘upstream multicast datagram tx allow’ requirement need to utilise a cross-connect VLAN per UNI. Therefore every UNI requires a Cross-Connect VLAN connected to a VPLS (not VVPLS) as opposed to a shared Residential Bridge. Upstream multicast is required for ‘zeroconf’ services, such as Bonjour and required for many printing services as well. Corporate LAN services therefore will have a reasonable percentage wanting, or having a reasonable expectation to support multicast Destination Address datagrams. This ‘cross-connect VLAN per UNI’ is therefore required as the PON Incidental GEM Port will be multicasted to all users including the sender via a Residential Bridge VLAN and the PC that sent it will detect a ‘duplicate IP address’ as the sender also receives the sent datagram and the device perceives that a device on the network also has a Source IP Address identical to its Source Address. This causes intermittent connectivity e2e. As Cross-Connect VLANs do not use Incidental GEM Ports to propagate multicast (or broadcast) frames, this issue is avoided. The differences and issues involved with each solution is demonstrated in Lab 4.

The 5571 PCC service template representations are as listed via ‘Service Type’. All services are VVPLS type except those listed as ‘VPLS’ as per the previous 2 slides explain:

CLI Build: Creating VVPLS Services
The following command covers the security access service: VLAN ID selected is ‘600’ LAG Group and 4 or 8 LT cards mapped (FX-4 or FX-8), example being an FX-8 Above is a VVPLS example for the Security Access Service. VLAN ID 600 is used as an example only (for the Security Access Service). Differences across the services respective VVPLS instances will be as follows: • ‘description’ argument should name the service, e.g., HSI, SURVEILLANCE, SECURITY’ etc. Lower case naming is also supported, label as preferred. • ‘600’: Is the VLAN ID and port SAPs in the example. Allocate the VLAN ID that the customer prefers. • All VVPLS instances will be created under ‘customer 1’. • The ‘qos 7’ allocation is the queuing mechanism for the Security Access service. Allocate different QOS IDs (profiles) per service. The Detailed Design explains the queue allocations per service and the QoS profiles are associated with this • Remove lt:1/1/5:<VLAN ID> to lt:1/1/8:<VLAN ID> (Line cards 5-8) if the FX-4 is used. Some services can have user2user communication enabled. It depends on the service, and also wether the service is a VPLS or VVPLS. The POL design documentation assesses the requirements of each service and recommends the combination of settings allowed, in this case user-user. See ‘5 Modes of Operation’ later in this training pack.

CLI Build: Creating VPLS Services (Desktop Data and an option for HSI)
The following command covers the Desktop Data/HSI service: VPLS (not VVPLS) selected is ‘100’ Cross-connect range (per UNI) VLAN ID start range is selected as ‘3000’ with ‘n + 1’ IDs Continue SAP allocations to LT:1/1/1, 2, 3,...4/8 as required. Above is a VPLS (not VVPLS) example for the ‘FTT-Desktop Data’ Service. VLAN ID 100 is used as an example only. Only data services (‘FTT-Desktop Data’ and ‘HSI Data’) requiring user2user and upstream multicast datagrams to pass require ‘VPLS + Cross-connect VLANs’ require this for their service as per the example. Nokia strongly recommends for desktop data to use this configuration method in all circumstances as implementing later requires widespread rebuilding of the configuration if for instance, printers are changed out and multicast datagram initiated print jobs are required later. Other differences across the services irrespective of being VPLS/VVPLS instances will be as follows: • ‘description’ argument should name the service, e.g., ‘FTT_DESKTOP_DATA’. Lower case naming is also supported, label as preferred. • ‘100’: Is the VLAN ID SAP in the example (uplink wise). Allocate the LT SAPs to match the Cross-connect VLAN IDs (per UNI port) in an allocation range that the customer prefers. Example is 3000 upwards, ‘n+1’. • All VPLS instances will be created under ‘customer 1’. • The ‘qos 9’ allocation is the queuing mechanism for the ‘FTT-Desktop Data’ service. Allocate different QOS IDs (profiles) per service as follows: VOIP_PBX=4, HSI=5, Public Announcement=6, Security Access=7, Surveillance=8, WiFi AP =10, Digital Signage=11, FTT Desktop=9. •The following services [can have] user2user communication enabled: VOIP_PBX, FTT Desktop (voice and data), therefore use the command ‘user-user-com’ in the VPLS to enable this.

Logical Architecture: LT Residential Bridge VLANs
An LT VLAN that matches the VVPLS VLAN ID is required for all services that ‘bond’ the ONT UNI Bridge Ports/LT Cards to the VVPLS VLAN instance Only 1 per Chassis for each service is required. This VLAN does not map to LT’s or LAG Group ports Secure Forwarding, New Broadcast Enablement & DHCP Option82 and queue access control are defined here The LT VLAN when built allows for the VLAN to be assigned to the customer ONT UNI port later in the service build process Used for all services except FTT-Desktop Data and HSI Data. As well as the VVPLS service declarations in the Ihub, an LT (i-bridge) VLAN is also required to be declared in the IACM (LT Card Group set, acronym meaning ‘Intelligent ASAM Core Module’). This singular service instance applies to all LT cards and does not require assignment to any ‘ports’ (NT ports or LT cards). This VLAN once created globally is then provisioned onto ONT UNI bridge ports to achieve e2e service connectivity. The LT VLAN contains many service setting options. Only a selection of the full capability are used for the POL services and are listed as follows: 1: Leave configured as default the disablement of ‘user2user communications’ for services that should not allow direct communications on the user (UNI) domain: HSI, Surveillance, WiFi Access Point, Security Access Control, Public Announcement and Digital Signage. 2: Enable ‘user2user communications’ within the VVPLS instances for where user2user connectivity is desirable: FTT Desktop data and voice, and VOIP/PBX (to ensure RTP is looped back to minimise traffic to/from IP PBX) 3: When user2user communications is a desired feature, ‘new broadcast enablement’ is also required (it is disabled by default) as a user needs to downstream broadcast to another user to communicate directly 4: When a Client/Server relationship is required where the client does not ‘seek’ a session, say a phone that has an ARP entry that has timed out, enable ‘new broadcast enablement’ to allow downstream broadcast (it is disabled by default) to ensure the server always can connect to the client. Example being an incoming call to a phone that has no ISAM ARP entry and the SiP softswitch is required to communicate SiP messaging with the phone. 5: Ingress-QoS profile: Maps all 802.1p markings to an appropriate QoS queue 6: Secure Forwarding: To ensure a heightened security, any fixed static IP address assigned to a device; if another device connects to the ONT UNI port, traffic will not pass for any device using another static IP address. Also, any DHCP issued address will have been snooped by the ISAM and only that source IP address traffic will pass. 7: DHCP Option 82: Will be turned ‘on’ to provide added fields for authentication. 8: Do not turn on ‘ipv4-mcast enable’!!! This capability should never be supported by Residential Bridge VLANs with ‘user-user com’ enabled in the VPLS. If this is required, cross-connect VLANs must be used instead. Read the Appendix sections of the CLI Installation and Configuration Guide to understand the interdependencies of these commands (3HV01415AAAAPCZZA).

Logical Architecture: LT Residential Bridge VLANs (cont)
@ CCTV - VLAN VoIP- VLAN CCTV VoIP IBridges for IP Voice/Digital Signage/CCTV VLAN ONT 1 D.S ONT 2 Digital Signage – VLAN Digisign I-Bridge CCTV @ Frames received from end users are either untagged or tagged: On a per UNI basis per ONT, VLAN IDs are configured ‘per service’ All customers using the same ‘service’ (e.g., IP voice, Digital Signage, CCTV etc) are ‘connected’ to the shared I-Bridge Service VLAN. Frames received from end-user as tagged or untagged are also sent back to user as single tagged or untagged. 3 examples shown are services that use Residential Bridge VLANs. Therefore Desktop Data services not included (that require cross-connect VLANs) Example: 3 Services connected, one VLAN per service per UNI Port

Logical Architecture: LT Cross-connect VLANs
An LT VLAN that matches the VPLS LT SAP VLAN ID Each SAP of the VPLS is added ‘n+1’ as a cross-connect VLAN is added to the service (per ONT UNI) 1 VLAN per UNI is required as opposed to 1 per Chassis Residential-bridge style VLAN Secure Forwarding can be defined here New Broadcast does not need applying (is not supported), it ‘just happens’ DHCP Option82 and queue access control are defined here The LT VLAN when built allows for the VLAN to be assigned to the customer ONT UNI port later in the service build process Used for FTT-Desktop Data and HSI Data only. As well as the VPLS service declarations in the Ihub, an LT (cross-connect) VLAN is also required to be declared in the IACM (LT Card Group set, acronym meaning ‘Intelligent ASAM Core Module’). This VLAN is created per UNI (ONT customer port) and is added onto each ONT UNI bridge port on an ‘n+1’ basis to achieve e2e service connectivity. The LT VLAN contains many service setting options. Only a selection of the full capability are used for the POL services and are listed as follows: 3: When user2user communications is a desired feature, ‘new broadcast enablement’ is also required (it is disabled by default) as a user needs to downstream broadcast to another user to communicate directly 1: Ingress-QoS profile: Maps all 802.1p markings to an appropriate QoS queue 2: Secure Forwarding: To ensure a heightened security, any fixed static IP address assigned to a device; if another device connects to the ONT UNI port, traffic will not pass for any device using another static IP address. Also, any DHCP issued address will have been snooped by the ISAM and only that source IP address traffic will pass. 3: DHCP Option 82: Will be turned ‘on’ to provide added fields for authentication. 4: ‘ipv4-mcast enable’ can be used with this VLAN type. Read the Appendix sections of the CLI Installation and Configuration Guide to understand the interdependencies of these commands (3HV01415AAAAPCZZA).

Logical Architecture: LT Residential Bridge + Cross-connect VLANs (cont)
@ CCTV - VLAN VoIP- VLAN CCTV VoIP IBridges for IP Voice/CCTV X-connects for desktop data VLAN ONT 1 Data ONT 2 Desktop Data – VLAN DATA I-Bridge X-connect CCTV Desktop Data – VLAN X-connect @ Frames received from end users are either untagged or tagged: On a per UNI basis per ONT, VLAN IDs are configured ‘per service’ All customers (excluding desktop data) using the same ‘service’ (e.g., IP voice, High Speed Internet, CCTV etc) are ‘connected’ to the shared I-Bridge Service VLAN. Desktop Data services use Cross-connect VLANs per UNI to connect into a singular WAN VLAN Frames received from end-user as tagged or untagged are also sent back to user as single tagged or untagged. Example: 3 Services connected, one VLAN per service per UNI Port

Logical Architecture: LT VLAN Creation
Residential Bridge: Example is ‘voice’ VLAN for FTT Desktop:

Logical Architecture: LT VLAN Creation
Cross-connect VLAN: Example is ‘HSI’ VLAN for data. Note the addition of the VPLS SAPs to the LT card. This example shows the addition of ipv4 mcast upstream enablement for printing services:

Logical Architecture: LT VLANs: DHCP Option 82
DHCP Option82: The TR156 standard, Section R127 page 36 defines the following: Access-Node-Identifier eth Slot/Port/ONUID/Slot/Port[:VLAN-ID] The following is an example of the DHCP Option 82 field via the 7360 FX VLAN defined via ‘physical ID’ format as follows: FX_PLATFORM_01 eth 1/1/01/01/4/1/1:10 Via a CLI argument within the VLAN, DHCP Option 82 is available for all services. This option is enabled for all VLAN services but can be disabled per service if required. The Channel Partner Installation and Commissioning Guide document details how this feature has been enabled. The ‘Friendly Name’ leading the Circuit ID complies with the TR156 standard. This can be variable in length but not exceed 63 characters, must be an ASCII character with no spaces in the field. This is referenced by the 7360 FX ‘name’ defined in the CLI in the build and configuration process (‘FX_PLATFORM_01’ being the example configured in the default image via the CLI command ‘configure system id’ and ‘configure system name’). The ‘eth’ character complies with TR156 as follows: ‘The Access-Node-Identifier, L2 type (ATM, ETH) field and the slot/port fields are separated using a single space character’ (page 39, TR156). It is separated by a space character either side and the ‘eth’ syntax is lower case. The slot and port identifiers cannot exceed 6 and 3 characters respectively inclusive of their ‘/’ delimiter. The example above is /rack/shelf/line card (1-8)/PON Port (1-16)/ONT (1-32)/Data Card (always 1)/UNI Port (1-4): <local VLAN>. Note that the ‘:10’ example above is the field advertised of the local C-VLAN-ID configured on the UNI customer facing and can contain a value of ‘:0-> 4095’. If a specific customer identification is required for authentication rather than the circuit ID, The Remote ID field can be used. This is linked to an operator settable Customer ID parameter setting on the local UNI (port) VLAN interface. Therefore, the entry of an alphanumeric character set in the Customer ID on the Local C-VLAN bridge interface will be mapped to the remote ID field in the DHCP Option82 tags.

Logical Architecture: LT VLANs: DHCP Option 82 (continued)
DHCP Option82: Customer ID parameters can also be set. Examples as follows: DHCP options: [82] Relay agent information: len = 49 [1] Circuit-id : FX_PLATFORM_01 eth 1/1/01/01/4/1/1 :10 [2] Remote-id: If a specific customer identification is required for authentication rather than the circuit ID, The Remote ID field can be used. This is linked to an operator settable Customer ID parameter setting on the local UNI (port) VLAN interface. Therefore, the entry of an alphanumeric character set in the Customer ID on the Local C-VLAN bridge interface will be mapped to the remote ID field in the DHCP Option82 tags. This will present as displayed above. The example above is a Remote ID entry of ‘ ’ within the customer ID field on the VLAN Bridge Interface of ‘VLAN 10’ on the UNI port of the ONT with a DHCP request. Note: The Remote ID can be presented as an alphanumeric (‘Aa-Zz, 0-9) to a maximum of 64 characters. All VLANs (services) are enabled to provide these fields. The service configurations will indicate how the Remote ID can be set during the service provisioning process. Separate CLI arguments can be added for DHCP Option82 for Ipv6 if this feature is required (by appending the existing commands with a ‘v6’ option).

Logical Architecture: ‘New Broadcast’
“…when ARP entries in the LT card reach a timeout, by default given that broadcast (hence ARP) is not permitted downstream, terminating calls on the customer telephony ports would not be received until an originating call is made, refreshing the ARP table via the allowed upstream (but not downstream) broadcast (ARP) mechanism. The per VLAN feature of ‘New Broadcast’ allows for downstream broadcast for i-Bridge VLANs where the ‘server’ needs to initiate connectivity to its ‘clients’ after the ARP table (and also FDB table) ages out…” This capability is enabled per VLAN and allows broadcasts (for instance ARP request packets) to be sent downstream. This capability only applies to Residential Bridge VLANs, for Cross-Connect, this capability is permanently ‘on’. This is critical for network located devices to populate their ARP cache with the MAC address of the destination device that the frame is being forwarded to. User-user communication also requires this as a user on one LT card requiring the sending of a broadcast ARP request will require this to be sent downstream via other LT cards to learn the other devices MAC address. For VLANs that also have Secure Forwarding enabled, the ARP request will only be forwarded out of the UNI that actually contains the IP address in the destination IP address field of the datagram/frame (as learned by the Secure Forwarding dynamic filter from the static IP address defined on the bridge port, or that learned from DHCP snooping). Note that in the CLI via OLT software release R4.6, that there are two commands; ‘broadcast-frames’ and ‘new-broadcast (inherit | enable | disable)’. Note that the latter is a full replacement for the former command and in later OLT software releases, the former command will be fully deleted. This is detailed in the R4.6 Alcatel-Lucent CLI Guide. Testing between other CLI arguments for new-broadcast (e.g., ‘inherit’, a system or S-VLAN inherited default) does provide e2e connectivity depending on whether DHCP or fixed IP’s are used, but the argument ‘enable’ works for all scenarios. Therefore in all user2user solutions, the argument is ‘new-broadcast enable’ in all circumstances for simplicity. Residential bridge VLANs can enable/disable this capability. For data services using cross-connect VLANs, this capability cannot be ‘turned on’, it is on by default.

Logical Architecture: ‘Secure Forwarding’
“…When enabled is IP session aware and snoops the DHCP offer messages to the ONT’s and caches the allocated DHCP IP address information and allows the flow of traffic if the source address is of the same address from the specific UNI port. If not, the traffic is discarded. Also for devices attached with static IP addresses, a static entry is required on the UNI bridge port when secure forwarding is enabled so the ISAM can ‘compare’ the configured IP address to the source address of the statically configured device in the data frame outgoing. If they do not match, the traffic is discarded…” ‘Secure Forwarding’ is an IP anti-spoofing feature and is applied at the VLAN level. Therefore every customer UNI port terminated to this VLAN inherits the ‘Secure Forwarding’ capability. Secure Forwarding performs the following: For static (fixed) IP addresses defined in the CLI and applied to the UNI bridge port/VLAN association, only packets with this Source Address upstream or a Destination Address downstream that matches is passed. All other broadcast frames are discarded. For DHCP assigned IP addresses (snooped and subsequently learned by the bridge port Secure Forwarding filter), the Secure Forwarding facility passes only packets with a Source Address of this ‘DHCP offer’ learned address upstream, or matching Destination Address downstream. All other broadcast frames are discarded. Also, for all UNI ports terminated to this VLAN defined as ‘secure forwarding’, ARP relay is performed when the ARP request is broadcast. What this means is that the LT card will only forward to the end user the ARP requests specific to the end user, i.e., ARP broadcasts with datagrams that contain the Destination IP address of the end device, and therefore forwards no other ARP broadcasts destined for other devices out that specific UNI interface. As applies for Residential Bridge VLANs: Although this is a port security measure (to prevent ‘theft of service’ by spoofing enacted by the end user), it is also essential to implement when system hair-pinning is set (and activated by the addition of ‘user-user-com in the VVPLS). As the Incidental Broadcast GEM port facility will send back the broadcast packets the device sends upstream through this port, the Secure Forwarding functionality will drop this broadcast ‘reflection’. Therefore as a broadcast packet from a device is sent through the Secure Forwarder function, the Incidental GEM Port frame ‘re-broadcasted’ back into this port is dropped because the ARP relay function inherent in the Secure Forwarding feature means that the Source Address of the Broadcast packet (heading downstream) matches the source address of the device (and should be the Destination Address), and therefore the Secure Forwarding filter will correctly drop this broadcast packet. If Secure Forwarding isn’t set on the VLAN of the service for this hairpin/user-user-com capability, this broadcast redistribution back into the port of broadcast origin (that in practical observations looks like a Broadcast received ‘reflection’ several milliseconds after the actual Broadcast packet was transmitted) causes potential issues. Some PC brands will temporarily cease to maintain e2e connectivity with peers when ARP/route tables are affected by packets sent to the PC (appearing to be from the network) with a Source Address matching the NIC card interface setting, indicating a duplicated IP address conflict. Also, downstream switches connected to ONTs, or ONT SFP connected switches have forwarding database re-convergences (that are incorrect) black-holing traffic due to this ‘reflected’ broadcast packet causing a MAC move from the access port of the device hosted, moving the MAC to the WAN uplink. Therefore, when ‘configure system user-user-hairpin’ is set, ‘new-secure-fwd enable’ MUST be set in the VLAN also to prevent these unwanted behaviours. Cross-Connect VLANs: These configurations do not require ‘new secure forwarding’ to prevent ‘ARP reflections’ as the incidental GEM port is not a facility used in Broadcast or multicast datagram propagation. Therefore the ‘protection’ of Secure Forwarding to prevent the issues described above is not required or necessary so the Secure Forwarding functionality is only required for the IP anti-spoofing feature if desirable.

Logical Architecture: ‘MAC Movement’
“…By default MAC Movement is blocked as a security measure to prevent spoofing and theft of service threats. A MAC address by default cannot move across LT cards (‘7360 FX chassis back plane ports’) for this reason…” Some services do require this movement E.g, WiFi AP service in which 2 adjacent WiFi Hotspots hosted via 2 different LT cards would eventuate in a wireless device MAC address instantaneously transitioning in the Forwarding Database from UNI to the next UNI. Therefore the WiFi AP service for example will have ‘MAC Movement allow’ enabled within the VLAN Within the VLAN per service, MAC movement can be allowed per VLAN. By default, a MAC address cannot move from one UNI to another within the MAC aging limit set in the VLAN (default 5 minutes). This is a security measure known as MAC anti-spoofing and is intended to prevent unauthorized device network ‘probing’ and by extension, malicious theft of service. By defining the extra VLAN argument ‘mac-movement-ctrl’, MACs can instantaneously move across different bridge port UNIs. This is desirable for wireless services in which the customers wireless device may transition different WiFi AP’s for instance, when devices/users are moving about the premises, transitioning different WiFi Access Points. Therefore this VLAN flag argument is activated to allow MACs to transition seamlessly across bridge port UNIs. Note that this capability does not need to be coupled with any other type of optional VLAN flag argument. Although other VLAN features may be coupled with ‘mac-movement-ctrl’, for instance, ‘ipv4-macst-ctrl’, if a tablet/mobile device is printing to a device using multicast protocols for instance, or ‘user-user com’ if WiFi connected devices need to connect internally within the OLT to other devices on the same service (VLAN).

Logical Architecture: ‘Hair-pinning’
“…To remove the LT port split horizon functionality for specific services, the ‘user2user hairpin’ global setting in the ISAM is enabled…” Deployed for VoIP PBX, FTT Desktop and Public Announcement/Intercom Allows direct user2user comms without egressing the 7360 FX. If Lawful Intercept and throughput usage counting (used for billing for instance) is required, this command argument should not be implemented Some POL services are suited to allowing user devices to directly communicate within the OLT without egressing the uplink. Peer2peer LAN PC traffic and RTP for telephony are examples of this functionality. There are several technical considerations that need to be accounted for if this forwarding model is to be used that are detailed later in this chapter. The addition of the ‘user-user-com’ command argument within the VVPLS allows an ONT UNI to communicate with any another ONT UNI on any other LT card/PON except its own LT card. Therefore broadcast (e.g. ARP) and unicast forwarding is achieved inter LT card via this command. Excluded functionality from this command is ONT UNI communication to other UNIs on the same ONT (‘intra ONT’), or other ONT UNIs on the same LT card (intra LT card and intra PON) irrespective of what PON they are on. To allow for ONT UNI devices to communicate to all other UNIs, including same LT hosted PON and ONT, the system wide ‘configure system user-user-hairpin’ command is also required. This command is already enabled in the baseline configuration the operator enters as defined in the detailed design therefore if ‘user-user-com’ is set in the VVPLS, full inter ONT communications is achievable. Again, DO NOT USE ‘user-user com’ with ‘ipv4macast enable’ with Residential Bridge VLANs.

Logical Architecture: ‘Multicast Upstream’
“…To facilitate multicast address range packet propagation (upstream) ‘IPv4 Multicast Control’ is enabled…” Deployed for, FTT Desktop Data/HSI Data and any services using upstream multicast packets. Allows packets with multicast destination IP addresses to propagate within the OLT. Potentially required in office LAN environment for some printer services that use multicast protocols, Zeroconf/Bonjour ONLY TO BE USED IN CROSS-CONNECT VLANs! Do not use in Residential Bridge VLANs For multicast (IPv4) packets to be able to be propagated upstream (therefore for any multicast capability to work), the service VLAN requires the argument ‘ipv4-mcast-ctrl’ added. Once this has been added, class D addressed datagrams ( > ) will be allowed to pass upstream and therefore protocols like ‘IGMP’ (for services like IPTV), ‘Bonjour’ (for LAN printing services and plug-n-play services) and general ‘Zeroconf’ protocol capabilities can be supported. Do not use in conjunction with Residential Bridge VLANs + user2user!!! See Lab 4 for the technical implications of this combination.

5571 PCC View of Service Creation
The Services are created via the Services creation window in the PCC as shown. Click the ‘+’ icon:

5571 PCC View of Service Creation (continued)
The Service is selected (LHS illustration), and the VLAN flag parameters are determined by the template on the RHS.

2 Bridge Ports & VLAN’s (ONT)

Generic Bridge Port Construct
This slide shows the basic parameter assignment per ONT UNI. There are many more parameters than these that can be set at ONT UNI levels and the hierarchies within it but are not covered via this POL solution training for reasons of simplicity. Both the G-240G-C and the G-040P-Q have 4 data UNI ports Each UNI port can have a MAC address learning limit on it. Up to 8 VLANs can be defined per UNI. Static IP addresses must be set per VLAN if static IP addressing is used (as opposed to DHCP) when ‘new secure forwarding enable’ is set in the VLAN (service). A default VLAN for untagged traffic (PVID) is set at bridge port level Traffic can be set for ‘untagged’ ingress/egress or for ‘single tagged’ ingress/egress Either ‘default Priority’ or ‘qos priority’ is used to define the preferred 802.1p bit marking for either encapsulation types for traffic into the network.

7360 FX Service Build: HSI via CLI
HSI requires 1 VLAN per UNI to be also configured 9 (as per slide 16). HSI Desktop Service: The ONT and ONT data-card (card ‘1’) is expected to have been built prior to the High Speed Internet service being built on the UNI as per the earlier training module. The following configuration is for an ONT UNI port supporting an untagged Ethernet interface. This is expected to be the most prevalent configuration option: <LT Card>: The NGLT-C/FGLT-A LT line card the ONT is connected to: LT card 1 -> 4/8 <PON Port>: The NGLT-C/FGLT-A LT line card PON port the ONT is connected to: 1 -> 8/16 <ONT number>: The ONT number on the respective PON: 1 -> 32 <UNI Port>: Data port, range 1 to 4. <BW Profile Name>: Choice of Customer. If a non blocking capacity at interface speed (contended) is desirable, enter in ‘DATA_UP_1G’. If a contained bandwidth is desirable, enter in ‘DATA_UP_50M’, ‘DATA_UP_100M’, ‘DATA_UP_200M’, ‘DATA_UP_300M’, ‘DATA_UP_400M’, or ‘DATA_UP_500M’. These are sample upstream bandwidth profile names ‘max-unicast-mac 4’: This is a nominal setting to protect the network from MAC broadcast storms and/or DOS attacks etc. Amend to value suitable if insufficient, on a per UNI basis. <unique alphanumeric ID used for DHCP Opt82 Customer ID>: e.g., ‘12345abcde’. <Shaper Profile Name>: Downstream, choice of Customer. If a non blocking capacity at interface speed (contended) is desirable, enter in ‘DATA_DOWN_1G’. If a contained bandwidth is desirable, enter in ‘DATA_DOWN_100M’, DATA_DOWN_200M’, ‘DATA_DOWN_300M’, ‘DATA_DOWN_400M’, or ‘DATA_DOWN_500M’. These are sample downstream shaper profile names ‘Default-priority 0’: This force marks all traffic untagged to 802.1p bit ‘0’ on ingress. Therefore BE classification is preserved e2e. <HSI Service VLAN ID>: The HSI data VLAN set earlier as ‘configure vlan id...’ qos-profile name:PASS_P0: The QoS filter for passing/dropping non compliant 802.1p service markings. This profile would need pre-configuring in the OLT prior to being able to be assigned.

7360 FX Service Build: FTT Desktop
FTT Desktop also requires the cross-connect data VLAN per UNI configured as per slide 16 FTT Desktop Service: The ONT and ONT data-card (card ‘1’) is expected to have been built prior to the High Speed Internet service being built on the UNI as per the earlier training module. The following configuration is for an ONT UNI port supporting an untagged Ethernet interface. This is expected to be the most prevalent configuration option: <LT Card>: The NGLT-C/NGLT-A LT line card the ONT is connected to: LT card 1 -> 4/8 <PON Port>: The NGLT-C/FGLT-A LT line card PON port the ONT is connected to: 1 -> 8/16 <ONT number>: The ONT number on the respective PON: 1 -> 32 <UNI Port>: Data port, range 1 to 4. <Queue 0 BW Profile Name>: Choice of Customer. If a non blocking capacity at interface speed (full PON bandwidth upstream contended) is desirable, enter in ‘DATA_UP_1G’. If a specific bandwidth rate is desirable, enter in ‘DATA_UP_50M’, ‘DATA_UP_100M’, ‘DATA_UP_200M’, ‘DATA_UP_300M’, ‘DATA_UP_400M’, or ‘DATA_UP_500M’. These are example upstream bandwidth profiles. <Queue 5 BW Profile Name>: Is set to ‘VOICE_UP_1M’. ‘max-unicast-mac 4’: This is a nominal setting to protect the network from MAC broadcast storms and/or DOS attacks etc. Amend to value suitable if 4 is insufficient to support all expected L2 addresses on a per UNI basis. <Queue 0 Shaper Profile Name>: Choice of Customer. Bandwidth service shaping per customer of ‘DATA_DOWN_1G’. If a specific (lower) bandwidth rate is desirable, enter in ‘DATA_DOWN_100M’, ‘DATA_DOWN_200M’, ‘DATA_DOWN_300M’, ‘DATA_DOWN_400M’, or ‘DATA_DOWN_500M’. These are example downstream shaper profiles. <Queue 5 Shaper Profile Name>: Is set to ‘VOICE_DOWN_1M’. <unique alphanumeric ID used for DHCP Opt82 Customer ID>: E.g, ‘12345abcde’ <local IP Phone VLAN>: The VLAN set in the IP Phone. Can be any value <Network Voice VLAN>: The FTT Desktop voice VLAN set earlier as ‘configure vlan id...’. <Network Data VLAN>: The FTT Desktop data VLAN set earlier as ‘configure vlan id...’. qos-profile name:PASS_P0_P5: The QoS filter for passing/dropping non compliant 802.1p service markings. This profile would need pre-configuring in the OLT prior to being able to be assigned.

Logical Architecture: Resiliency
All LT cards are connected to an ‘A’ and ‘B’ back-plane bus Either NT-A or NT-B can be ‘active’ The alternate NT card assumes an ‘active’ role and LT cards will forward to the new active NT card The illustration above shows the backplane connectivity to the NT-A and NT-B controllers and in the event of a control card failure, the alternate backplane is used. The Link Aggregation NNI uplinks will connect in an ‘active/active’ state from optical links via both controller cards. The Channel Partner and their Customer is expected to factor in an e2e resiliency model that the uplink switch/router that the 7360 FX is connected to has sufficient fibre path ‘A’ and ‘B’ resiliency and potentially, card/blade and/or multi chassis resiliency dependent on the core switch vendor implementation.

3 Quality of Service

Quality of Service Overview
Three domains for Quality of Service Enforcement: ONT UNI Port Queues LT Line Card Ihub v-VPLS (VLAN) QoS is performed at layer 2 (Ethernet) As QoS is performed at layer 2 (Ethernet), with the possible range of eight 802.1p markings in the VLAN tags for QoS classification, the GPON 7360 FX has 8 unicast forwarding queues enabled via the UNI interface customer facing, the PON/LT interface and the NNI (Network facing) uplink interfaces via the Ihub. Therefore hierarchically (from the UNI to the NNI network uplink), QoS capability is consistent end to end. There is also another selection of queues for multicast, voice and ISAM OAM in strict priority also (downstream). All voice services will forward via the dedicated voice queue downstream. All POL service solutions (excluding downstream voice) will be designed to forward via one of the these 3 hardware domains 8 respective unicast forwarding queues via a Strict Priority (SP) queuing mechanism, in which 802.1p ‘7’ has the highest priority and conversely 802.1p ‘0’ has the lowest priority. Downstream voice will be the exception and will forward via the dedicated voice forwarding queue. Only FTT Desktop is expected to have 2 cohabiting POL services on the UNI port, both voice and data VLANs combined (via an IP phone with PC connected). Therefore this service instance will differ slightly from the other configurations to achieve QoS differentiation.

Quality of Service: Upstream
All Services (except FTT Desktop): On ingress to the UNI the untagged Ethernet frames from the end device will be force marked a C-VLAN tag and C-VID ID and an 802.1p marking (dependent on the service) This ensures that forwarding to the appropriate queue for Strict Priority assignment and bandwidth policing occurs. Therefore no differences in traffic priority exist per UNI interface so all flows from the external device are not required to be treated differently. If end device is VLAN tagged, the service will translate the end devices C-VLAN-ID and also force re-write the 802.1p marking to queue accordingly

Quality of Service: Upstream
FTT Desktop: 2 classes of service for the FTT Desktop service; ‘Internet’ and ‘voice’ for the singular UNI. The IP phone is C-VLAN ID tagged to/from the IP phone (any C-VLAN ID value). This devices C-VLAN-ID will be translated to the network (voice service C-VLAN ID) and force written an 802.1p = ‘5’ and sent upstream. The PC connected to the IP phone (untagged) will be sent into a ‘data’ VLAN; then tagged a C-VLAN tag and C-VID ID by the service and force marked an 802.1p = ‘0’. On ingress the untagged Ethernet frames from the end device will be force marked a C-VLAN tag and C-VID ID and an 802.1p marking (dependent on the service)

QoS: Traffic Bandwidth Controls
Upstream: Committed, Assured and Excess Data rate assignment to the upstream capacity Gbps available per PON interface Bandwidth assigned is set to provide a peak Ethernet rate specified in the bandwidth profile. Traffic sent upstream (into the ONT UNI destined for the network) will be subjected to bandwidth containment, enforced by a bandwidth profile applied. Only 1 QoS UNI queue in the upstream will be assigned a bandwidth profile as per the 802.1p bit (force marked) upstream, except for FTT Desktop that has 2 queues, therefore 2 bandwidth profiles (queue 0 and queue 5 in this service instance example). The bandwidth will contain a committed, assured and excess information rate depending on the POL service defined with priority on the PON shared medium in this order of precedence. In a UNI traffic congestion scenario, traffic will be discarded once it exceeds the peak rate defined in the bandwidth. This occurs before it is sent upstream on the PON shared medium to the LT card. The bandwidth profiles available to the various POL service concepts will depend on the service concept itself and the expected traffic that requires to be passed (and potentially policed by the bandwidth profile) upstream. For instance, a 100 kbps voice RTP traffic stream will require a different bandwidth profile assigned to the queue than that of a bandwidth profile assigned to a queue carrying a High Speed Internet ‘www’ internet traffic stream. The former service is of a higher priority and cannot be policed whereas the internet traffic can potentially be policed under congestion scenarios. Depending on the type of customer traffic expected on the PONs it is therefore recommended that careful forecasting, planning and management of PON bandwidth utilization be employed if congestion of these peak rates is to be expected. The POLT utilizes Dynamic Bandwidth Assignment (DBA) for managing upstream bandwidth allocation on the PON. By servicing the differing traffic classification hierarchy based on priority (CIR, AIR, EIR) defined in the bandwidth profiles per service flow, the DBA algorithm takes into account the provisioned bandwidth limits such as Committed Information Rate (CIR), Assured Information Rate (AIR) and Extended Information Rate (EIR), bandwidth availability and current bandwidth demands from the T-CONT’s (T-CONTs are underlying frames in the G defined physical layer).

QoS: Upstream Queue Example 1
Upstream Untagged: Example of the Surveillance Service using queue 2 and 802.1p ‘2’ force marking Upstream Untagged: This is expected to be the most prominent capability. Traffic is sent upstream untagged from the end device, force marked an 802.1p = ‘2’ and mapped to the Service VLAN/VVPLS C-VLAN ID which has been stipulated by the Channel Partner/Customer. C-VLAN ID 200 has been illustrated as an example.

Upstream Tagged: Example of the Surveillance Service using queue 2 (tagged) and 802.1p ‘2’ force marking Upstream VLAN tagged: This is expected to be the least prominent capability but may be desirable by a customer. Traffic is sent upstream with a C-VLAN ID of the customer’s choice. This will be force marked an 802.1p = ‘2’ and the C-VLAN ID will be translated to the Service VLAN/VVPLS C-VLAN ID which has been stipulated by the Channel Partner/Customer. Local C-VLAN ID 20 (CCTV camera) and network C-VLAN ID 200 have been illustrated as an example.

Upstream Tagged and Untagged: Example of the FTT Desktop Service using queue 0 (untagged) and queue 5 (tagged) FTT Desktop Combination: Upstream VLAN tagged & Untagged: As per the illustration above, traffic is sent upstream from the IP Phone with a C-VLAN ID and 802.1p value of the customer’s choice (C-VLAN ID ‘50’ on the IP phone). The 802.1p value will be force marked an 802.1p = ‘5’ and the C-VLAN ID will be translated to the Service VLAN/VVPLS C-VLAN ID which has been stipulated by the Channel Partner/Customer for the voice, in this example C-VLAN ID 500. The PC will send untagged traffic and be forced marked a C-VLAN ID for the service stipulated by the Channel Partner/Customer. The reason this is required is to be able to segregate the IP phone and PC by 2 x C-VLANs so each subnet is separated.

Quality of Service: Downstream
High Speed Internet: All p-bits will be forwarded via ‘be’ queue0 Surveillance: All p-bits will be forwarded via ‘af’ queue2 WiFi Access Point: All p-bits to be forwarded via ‘be’ queue0 Security Access Control: All p-bits to be forwarded via ‘l1’ queue3 Public Announcement: All p-bits to be forwarded via ‘l1’ queue3 Digital Signage: All p-bits to be forwarded via ‘l1’ queue3 VOIP/PBX: All p-bits will be forwarded via ‘ef’ queue5 FTT Desktop: Data p-bits will be forwarded via ‘be’ queue0, the voice via ‘ef’ queue5 For all services on ingress to the 7360 FX (except FTT Desktop), on a per VVPLS/VPLS (VLAN tag value) basis, it is expected that the ingress priority markings from the network for the various services need to be a specific 802.1p value service dependent. This is not critical for the Ihub VVPLS/VVPLS function but definitely for the LT card VLAN. Within the Ihub itself, a service-ingress policy is applied to each VPLS/VVPLS service instance to map all traffic flows to a singular queue per service irrespective of 802.1p markings. There are 8 queues in order of precedence from lowest priority to highest as follows: ‘be’ (best efforts), ’l2’ (low 2), ‘af’ (assured forwarding), ‘l1’ (low 1), ‘h2’ (high 2), ‘ef’ (expedited forwarding), ‘h1’ (high 1), and ‘nc’ (network control) p markings will be mapped to these queues on ingress downstream into the ISAM, and also ‘ingress’ into the VPLS/VVPLS instance upstream from the LT boards. The traffic class and queuing are as referred to in the slide above.

Quality of Service: Downstream (continued)
Traffic Class/Queue/802.1p marking alignments: In the downstream, the 7360 FX is the ‘master’ and does not receive Dynamic Bandwidth requests from the ONT as per the upstream scenario. Downstream prioritisation will depend on traffic priority markings and the per service shaping profiles applied per UNI (enforced at the LT/PON interface). Above is a Table illustrating the differences between 802.1p markings, the equivalent DSCP markings (if sent e2e via customer L3 traffic) and the associated Ihub traffic class classifications, which differ naming convention wise to the IACM (LT card) naming methodology.

QoS: Downstream UNI Filtering
High Speed Internet: Only p-bit ‘0’ will be forwarded Surveillance: Only p-bit ‘2’ will be forwarded WiFi Access Point: Only p-bit ‘0’ will be forwarded Security Access Control: Only p-bit ‘3’ will be forwarded Public Announcement: Only p-bit 3 will be forwarded Digital Signage: Only p-bit 3 will be forwarded VOIP/PBX: Only p-bit 5 will be forwarded FTT Desktop: Data p-bit ‘0’ and the voice p-bit ‘5’ will be forwarded An ingress filter will be provisioned per ONT UNI bridge port (in practice, per UNI service) that accepts only the 802.1p marking value expected by the service from the network for the downstream directional traffic flow. This is essential for the ONT QoS (and in the use case of network to local C-VLAN translation) to function correctly. The filtering functionality is as shown in the slide above.

4 POL Services: FTT Desktop

POL Service: FTT Desktop
FTT Desktop as a service comprises of 1 VLAN/VVPLS for voice and 1 VPLS/many VLANs for data segregation Hosts end user electrical (RJ45) Ethernet 802.3/Ethernet II PC’s and IP phones using untagged and singular 802.1Q VLAN tag respectively. MAC address limit of ‘16’ per UNI (settable if required to be more). Data capability: 1G interface speed via RJ45 (via IP Phone) with minimum 100 Mbps ‘Best Efforts’ steps (up to 1G customer settable) bidirectional traffic bandwidth nominally provided per user. This can be modified in 100Mbps steps to a higher bandwidth (1G bidirectional, contended) via bandwidth profiles based on the customer preference. Traffic from the network to the user will be prioritised against any other 7360 FX services via ‘strict priority’ precedence. FTT Desktop data services will be treated as ‘best efforts’ (802.1p/traffic class = ‘0’/be). Upstream from UNI (in the Use Case of an IP phone): Is connected to the ONT UNI with a daisy-chain connected PC, the telephony traffic flow must send an 802.1Q tag (C-VLAN ID tag value at discretion of customer, 802.1p tag ID can be anything and will be overwritten) and the C-VLAN ID and 802.1p value will be translated to the service VLAN/p-bit to obtain an expedited forwarding QoS. Residential Bridge VLAN ID is ‘200’ in this example e2e. The PC connected to the phone is as expected, untagged traffic. This will be by default connected to a data (cross-connect) VLAN (different VLAN per UNI). Example is PC 1,2,3 being cross-connect VLANs 3000, 3001, 3002 translated to a WAN VLAN of ‘100’. Downstream to the UNI: The network must send toward the 7360 FX for the voice component an 802.1p of ‘5’ for the SIP/RTP traffic on the voice VLAN or the IP phone will not SIP register. Downstream to the UNI: The network must send toward the 7360 FX for the data component an 802.1p value of ‘0’ for the data traffic on the data VLAN. The ONT will strip the VLAN header and forward the frames untagged to the PC connected to the IP phone. WiFi capability that is required will not be provided via the ONT infrastructure. This will need to be provided by customer CPE equipment. The 7360 FX POLT will contain an 802.1Q VLAN per UNI port (for the data capability) and another 802.1Q VLAN (singular chassis wide)for the voice to host FTT Desktop users. In practice, the ‘voice’ VLAN can be the VOIP PBX VLAN which is listed as a separate service later in this document. The FTT Desktop capability will feature an ‘open’ (user2user) LAN segment that emulates a typical Ethernet switch that allows communication direct between ONT UNI ports within the GPON domain for voice and data. The FTT Desktop solution will have typical protocol transparency (ONT model dependent) for corporate LAN based type traffic. The capability is not expected to carry protocols such as routing protocols (e.g., OSPF, BGP, ISIS etc) or L2 control protocols (e.g., like LAG, RSTP etc) to/from the UNI (customer) ports. The FTT Desktop solution is expected to host all server farms, printers, DHCP servers and externally hosted applications on the NNI (WAN) side, with Personal Computing/telephony (and optionally WiFi and PDA/tablet device) capability only on the ONT (UNI) side of the solution.

POL Service: FTT Desktop (continued)
Traffic Forwarding: Voice VVPLS set for user2user comms, cross-connect data VLANs shared VPLS set for user2user comms also. QoS Upstream: A local VLAN is specified in the IP Phone. It can be any value. This C-VLAN ID is configured as a ‘local VLAN’ in the ONT bridge port. This can be translated to the ‘network VLAN’ value if different IDs used Voice: An 802.1p bit is force marked a p-bit value of ‘5’, therefore the p-bit value sent from the IP phone is ignored. Data: The ONT Bridge port is specified a ‘default VLAN’ (pvid) that forwards untagged traffic (from the PC) to the FTT Desktop ‘data’ (cross-connect) VLAN. On the downstream, the traffic is untagged and forwarded to the PC. Traffic Forwarding: The voice VVPLS VLAN connecting the LT cards to the LAG uplink are both set for ‘user2user communications’ and ‘new broadcast enablement’, although some customers may not want user—user set in the voice VLAN, so this is optional. Direct communications between users (without forwarding back up into the network) through the 7360 FX backplane is therefore possible for this service (for voice capabilities), thus minimizing unnecessary traffic from traversing the network (as mentioned, if this is desirable). If billing and lawful intercept is a requirement, user2user communications can be disabled. Secure forwarding will be an optional security enhancement at the customer’s discretion. Note that the Desktop data component is a ‘VLAN per UNI’ joined up by a singular VPLS, whilst the voice is 1 shared Residential Bridge VLAN also joined into a singular VVPLS structure. The Data service can still do user2user communications via this cross-connect VLAN method.

Upstream, Queue 0: Intended for Best Efforts data traffic from the PC, Excess Information Rate (‘non guaranteed’) of 100 Mbps, 200 Mbps -> 500 Mbps or 1Gbps assigned based on customer preference. This is applied as a bandwidth ‘profile’, e.g., ‘DATA_UP_1G’. Upstream, Queue 5: Intended for the Voice traffic: Committed Information Rate bandwidth assigned (‘guaranteed’) of 1 Mbps. Upstream: • A local VLAN is specified in the IP Phone. It can be any value. This C-VLAN ID is configured as a ‘local VLAN’ in the ONT bridge port. This is translated to the network VLAN defined for the solution by the customer via the ONT. An 802.1p bit is force marked a p-bit value of ‘5’, therefore the p-bit value in the IP phone is irrelevant. • The ONT Bridge port is specified a ‘default VLAN’ (pvid) that forwards untagged traffic (from the PC) to the FTT Desktop ‘data’ cross-connect VLAN. On the downstream, the traffic is untagged and forwarded to the PC. • Queue 0 (intended for Best Efforts data traffic from the PC): Excess Information Rate (‘non guaranteed’) of 100 Mbps, 200 Mbps -> 500 Mbps or 1Gbps assigned based on customer preference. This is applied as a bandwidth ‘profile’, e.g., ‘DATA_UP_1G’. • Queue 5 (intended for the Voice traffic): Committed Information Rate bandwidth assigned (‘guaranteed’) of 1 Mbps. This is applied as a bandwidth ‘profile’, e.g., ‘VOICE_UP_1M’. • As the G-240G-C does not have a PoE capability this is not expected to host IP phones as it is requiring external IP phone power supplies.

Qos Downstream: Queue 0 Shaper (Best Efforts data traffic): Committed rate component and Excess Information Rate (‘non guaranteed’) of 100 Mbps, 200 Mbps -> 500 Mbps or 1Gbps Queue 5 Shaper (Voice traffic): Committed Information Rate bandwidth assigned (‘guaranteed’) of 1 Mbps (channeled via a dedicated voice queue in the LT) Filtering: Downstream, 802.1p values must be ‘0’ and ‘5’ for data and voice (RTP and SIP) respectively or traffic will be dropped. Downstream: • Queue 0 (intended for Best Efforts data traffic): A committed rate component and an Excess Information Rate (‘non guaranteed’) of 100 Mbps, 200 Mbps -> 500 Mbps or 1Gbps is assigned based on customer preference via a shaper profile, e.g., DATA_DOWN_1G. Queue 5 (intended for the Voice traffic): Committed Information Rate bandwidth assigned (‘guaranteed’) of 1 Mbps. Note, this is for security purposes bandwidth protection only and should only ‘shape’ in non standard (e.g., DoS) scenarios. Implemented by a shaper profile, e.g., ‘VOICE_DOWN_1M’. Note that even though a shaper is applied to queue 5, the voice is channeled via a dedicated voice queue in the LT so is exempt from the strict priority drop precedence of the 8 unicast queues. Filtering: Downstream, 802.1p values must be ‘0’ and ‘5’ for data and voice (RTP and SIP) respectively or traffic will be dropped.

5 POL Services: High Speed Internet Service

POL Service: High Speed Internet
High Speed Internet as a service comprises of 1 VLAN per ONT UNI for data. [There is also an option for x-connect VLANs per UNI]: The 7360 FX and ONTs for this service concept will have the capabilities and meet the following requirements: • Hosts end users via electrical (RJ45) Ethernet 802.3/Ethernet II or devices (e.g., RGW’s) using a singular 802.1Q VLAN tag per customer UNI. • 10/100/1000Mbps RJ45 interface speed with 100 Mbps ‘Best Efforts’ bidirectional traffic bandwidth nominally provided per user. This can be modified in 100Mbps steps to a higher bandwidth (1G bidirectional, contended) based on the customers preference. • Traffic from the network to the user will be prioritised against any other 7360 FX services via ‘strict priority’ precedence via 802.1p. HSI data services will be treated as ‘best efforts’ (802.1p = ‘0’) and must be sent from the network as 802.1p = ‘0’. Example is 3 x cross-connect VLANs per UNI connected to a VPLS with a WAN uplink VLAN ID of ‘100’ in his example. • WiFi capability that is required will not be provided via the ONT infrastructure. This will need to be provided by customer CPE equipment. • The 7360 FX POLT will contain an 802.1Q VLAN C-VLAN ID per customer UNI (n+1) to host the HSI Service, all converted to a singular 802.1Q C-VLAN ID on the WAN side (example is VLAN ID 100). • The HSI capability will retain the default configuration disablement of user2user connectivity within the GPON domain forcing traffic to be handled to/from an external Gateway (for instance, the external Service Providers BNG). This facilitates in billing on all sent and received traffic and any potential lawful intercept requirements. • This service capability is not expected to carry protocols such as routing protocols (e.g., OSPF, BGP, ISIS etc) or L2 control protocols (e.g., like LAG, RSTP etc) to/from the UNI (customer) ports. • The HSI solution is able to support Residential Gateways on the ONT (UNI) side. • MAC address limit of ‘16’ set per UNI (can be modified based on customer preference). There is also a 5571 PCC option for a xconnect/VPLS option if required. This is not envisaged to be a prevalent option. If, like the FTT_Desktop ‘data’ service requirements are needed (user-user, and IP4/4 upstream multicast) at the same time, the ‘VPLS’ option of this service utilizing xconnect VLANs per UNI, and a VPLS will be the option to select.

POL Service: HSI (continued)
An untagged interface is specified on the ONT UNI port that is forwarded to the HSI VLAN ID The ONT Bridge port has specified a ‘default VLAN’ (pvid) that forwards untagged traffic (from the PC) to the HSI VLAN. On the downstream, the traffic is untagged and forwarded to the PC. An 802.1p bit is force marked a p-bit value of ‘0’ QoS Upstream: Queue 0: Intended for Best Efforts data traffic from the PC, Excess Information Rate (‘non guaranteed’) of 100 Mbps, 200 Mbps -> 500 Mbps or 1Gbps assigned based on customer preference. This is applied as a bandwidth ‘profile’, e.g., ‘DATA_UP_1G’. Traffic Forwarding: The VVPLS VLAN connecting the LT cards to the LAG uplink for the HSI service is set (with default configuration intention) to prohibit user2user communications. As this service is effectively a ‘trunked’ service from an external Service Provider, ‘new broadcast enablement’ is not necessary as the BNG will never initiate connectivity to the client; only the client initiates connectivity to the BNG (via DHCP for instance). Secure Forwarding is an optional feature but again, not necessarily relevant as the external service provider will have implemented their own internal security features for anti spoofing, theft of service etc. Therefore if User2user is actually prohibited, a Residential Bridge (shared VLAN) could theoretically be used for this service. But , the service is built as ‘cross-connect per UNI’ anyway, in case user-user is ever implemented, with IPv4-mcast also in the future. It is at the discretion of the operator to proceed building the HSI Data device with 1 Residential Bridge VLAN instead of cross-connect VLANs per UNI if it is absolutely certain that the user-user facility is never going to be used. A Bandwidth profile is applied to 1 of the 8 queues in the upstream for Best Efforts. Shaping will be implemented downstream also. Configuration specifics are as follows: Upstream: • The incoming traffic is expected to be untagged Ethernet. A forced marking of 802.1q = ‘0’ for all ‘data’ ingress traffic upstream (from the UNI) will be performed and the service C-VLAN ID will be added. • If there is a Residential Gateway attached to the ONT UNI, it can send an 802.1Q tag value of any C-VLAN ID tag value (which is ID translated) or 802.1p marking (the marking being overwritten). • Queue 0 (intended for Best Efforts data traffic): Excess Information Rate (‘non guaranteed’) of 100 Mbps, 200 Mbps -> 500 Mbps or 1Gbps is assigned based on customer preference.

POL Service: HSI (continued)
Qos Downstream: Queue 0 Shaper (Best Efforts data traffic): Committed rate component and Excess Information Rate (‘non guaranteed’) of 100 Mbps, 200 Mbps -> 500 Mbps or 1Gbps Filtering: Downstream, 802.1p values must be ‘0’ for data or traffic will be dropped. Downstream: Queue 0 (intended for the data Best Efforts traffic): A committed rate component and an Excess Information Rate (‘non guaranteed’) of 100 Mbps, 200 Mbps -> 500 Mbps or 1Gbps assigned based on customer preference. Filtering: Downstream HSI traffic 802.1p priority values must be marked ‘0’ or traffic will be dropped.

6 POL Services: Security Access Control

POL Service: Security Access Control
Supports an IP based Access Reader/Controller technology solution. Example shown combines CCTV and Security Access The Security Access solution is intended to support an IP based Access Reader/Controller technology solution. The topology of this solution is assumed to be a centralised control architecture point to multipoint connectivity in a client server relationship. In most cases very low signalling traffic bandwidth is required. 1 Mbps Committed Information rate assigned per device downstream, but up to 10 Mbps upstream for instantaneous high data transfer for worst case bandwidth scenarios, for instance, detailed biometric imaging data (fingerprints, retina scans etc) via MJPEG. Upstream: QoS will be via 802.1p alignment in which the ONT will ‘force mark’ 802.1p = ‘3’ upstream with the solutions VLAN tag (‘low1’ traffic class, assigned to queue 3 in the Ihub v-VPLS and ONT/LT queuing also). Downstream: The service traffic must be sent as 802.1p = ‘3’ towards the UNI or will be discarded. 10/100/1000Mbps RJ45 interface with Power over Ethernet (PoE) which can be enabled with different powering levels on a per port basis. The Installation and Configuration Guide covers the PoE setting options per ONT UNI port dependent on the Security Access vendor requirements. The Physical Access Control panels and application platform will be provided by the customer: Negotiated via Access Control Directories such as Cisco Physical Access Manager or Microsoft Active Directory for instance. The solution is anticipated in some use cases to be incorporated with the Surveillance solution also for monitoring purposes alongside the security capability. The 7360 FX POLT will contain a singular chassis wide 802.1Q C-VLAN ID set at the customers discretion to host the security access devices and NNI connected application control platform. The Security Access solution is expected to host all Security Access Controller platform(s) on the Network side (not the ONT UNI side) of the 7360 FX Platform.

POL Service: Security Access Control (cont)
Traffic Forwarding: 1 VLAN used prohibiting user2user comms. QoS Upstream: An untagged interface is specified on the ONT UNI port that is forwarded to the Security Access Control VLAN ID. A VLAN tagged interface (access device facing) can also be configured if desirable An 802.1p bit is force marked a p-bit value of ‘3’, therefore the p-bit value (if the device does send VLAN tags) is irrelevant and is overwritten. The ONT Bridge port has specified a ‘default VLAN’ (pvid) that forwards untagged traffic (from the PC) to the Security Access Control VLAN. On the downstream, the traffic is untagged and forwarded to the PC. Traffic Forwarding: The VVPLS VLAN connecting the LT cards to the LAG uplink for the Security Access Control service is set (with default configuration intention) to prohibit user2user communications. Communication of Access Control Devices should only communicate in a client/server relationship. Secure forwarding and New Broadcast enablement will also be enabled as communication e2e data flows may be initiated from either side with long durations between requiring ARP in both directions, and traffic flows will require robust security measures to prevent a customer spoofing attempt.

Upstream, Queue 3: Intended for ‘low1’ data traffic from the Access Control Device, Committed & Assured Information Rate of 10 Mbps. This is applied as a bandwidth ‘profile’ A Bandwidth profile is applied to 1 of the 8 queues in the upstream for the ‘Low1’ data. Shaping will be implemented downstream also. Configuration specifics are as follows: Upstream: A forced marking of 802.1p = ‘3’ for all ingress traffic upstream (from the UNI). Queue 3 (intended for Security Access signalling traffic): A ‘committed’ and ‘assured’ bandwidth rate totalling 10 Mbps. A high bit-rate specified anticipating high instantaneous bandwidth transaction for detailed biometric MJPEG information. If a device connected to the UNI is 802.1Q tag capable and is sending 802.1Q frames upstream, the data stream can be any 802.1p marking; the network will force mark it to 802.1p = ‘3’. The C-VLAN ID will be translated to the network service C-VLAN ID.

Qos Downstream: Queue 3 Shaper: Committed rate component (‘guaranteed’) of 1 Mbps Filtering: Downstream, 802.1p values must be ‘3’ for data or traffic will be dropped. Downstream: Queue 3 (intended for the Security data traffic): A committed rate component of 1 Mbps. Filtering: The service must send downstream traffic to the customer UNI as 802.1p = ‘3’ or the traffic will be discarded.

7 POL Services: Digital Signage

POL Service: Digital Signage
Utilities sites like metro subways, airports, motorways, HD advertising in Shopping precincts, Festivals, Events etc displaying enriched video content. It is likely that the content will differ from site to site so multicast will not be factored into the design at this stage. Bandwidth replication inefficiency is not of concern for textual digital signage due to low bandwidth requirements as opposed to HD/UD advertising content that will have higher bandwidth requirements. If the market dictates that a multicast digital signage content solution is required, a later edition of this design will address a multicast design for digital advertising content. The solution requirements are as follows: • The solution will host end user devices via electrical (RJ45) Ethernet 802.3/Ethernet II or devices, or using a singular 802.1Q VLAN tag (e.g., RGW’s). • 10/100/1000 Mbps interface speed with asymmetric rates of ‘low1/Assured Information Rate’ bidirectional traffic bandwidth provided per user. 10 Mbps downstream in all instances (assuming HD advertising content worst case scenario), 1 Mbps upstream for signaling and polling purposes. • In the scenario the Digital Signage device requires PoE, the Installation and Configuration Guide covers the POE settings per ONT UNI port dependent on the Security Access vendor requirements. • Upstream: Traffic from the network to the user will be prioritised against any other 7360 FX services via ‘strict priority’ precedence via 802.1p. Digital Signage services will all be treated as ‘low 1’ (802.1p = ‘3’). • Downstream: The service traffic must be sent as 802.1p = ‘3’ towards the UNI or the traffic will be discarded. • If WiFi capability is required, this will not be provided via the ONT infrastructure. This will need to be provided by customer CPE equipment if required. • The 7360 FX POLT will contain a singular chassis wide 802.1Q VLAN (defined at the customers discretion) to host the Digital Signage Service. • The Digital Signage capability will retain the default configuration disablement of user2user connectivity within the GPON domain forcing traffic to be handled to/from the external Content Server/Operator Input Terminal in a client/server arrangement. • This service capability is not expected to carry protocols such as routing protocols (e.g., OSPF, BGP, ISIS etc) or L2 control protocols (e.g., like LAG, RSTP etc) to/from the UNI (customer) ports. • The Digital Signage solution is able to support Residential Gateways on the ONT (UNI) side if desirable. • MAC address limit of ‘4’ set per UNI (settable).

POL Service: Digital Signage (cont)
New Broadcast: Enabled Traffic Forwarding: 1 VLAN used prohibiting user2user comms. QoS Upstream: An untagged interface is specified on the ONT UNI port that is forwarded to the Digital Signage Service VLAN ID. A VLAN tagged interface (Display facing) can also be configured if desirable An 802.1p bit is force marked a p-bit value of ‘3’, therefore the p-bit value (if the device does send VLAN tags) is irrelevant. The ONT Bridge port has specified a ‘default VLAN’ (pvid) that forwards untagged traffic (from the PC) to the Digital Signage Service VLAN. On the downstream, the traffic is untagged and forwarded to the PC. Traffic Forwarding: The VVPLS VLAN connecting the LT cards to the LAG uplink for the Digital Signage service is set (with default configuration intention) to prohibit user2user communications. New Broadcast enablement will be enabled as communication e2e data flows may be initiated from either side with long durations between requiring ARP in both directions. Secure Forwarding is recommended given the public domain these devices are located in physically and the potential for malicious access attempt. This is a configuration option that can be implemented optionally by the customer.

POL Service: Digital Signage (cont)
Qos Downstream: Queue 3 Shaper: Committed and Excess data rate component (‘guaranteed’) of 10 Mbps (HD content capable) Filtering: Downstream, 802.1p values must be ‘3’ for data or traffic will be discarded. Downstream: Queue 3 (intended for the Digital Signage Display traffic): A committed and excess rate component of 1/10 Mbps respectively. Filtering: The service must send downstream traffic to the customer UNI as 802.1p = ‘3’ or the traffic will be discarded.

8 POL Services: Surveillance

POL Service: Surveillance
Surveillance service designed to host CCTV cameras via ‘Power over Ethernet’ capability: The 7360 FX and ONTs for this service concept will have the following capabilities and requirements: 10/100/1000Mbps interface speed with rate ranges to 20 Mbps upstream (vendor dependent) via ‘af’ (assured forwarding) class of service/bandwidth assignment. The PoE settings required are detailed in the Configuration and Installation Guide which covers the POE settings per ONT UNI port dependent on the CCTV vendors requirements An ONT variant G-040P-P (or future POE capable ONTs) providing PoE capability will allow the CCTV cameras to be powered independently of an external AC/DC power supply. The solution will host end user devices via electrical (RJ45) Ethernet 802.3/Ethernet II devices, or using a singular 802.1Q VLAN tag if required. Upstream: Traffic from the network to the user will be prioritised against any other 7360 FX services via ‘strict priority’ precedence via 802.1p. The Surveillance service will all be treated as ‘assured forwarding’ (802.1p = ‘2’). Downstream: The service traffic must be sent as 802.1p = ‘2’ towards the UNI or traffic will be discarded. WiFi capability is out of scope. The 7360 FX POLT will contain a singular chassis wide 802.1Q VLAN (defined at the customers discretion) to host the Surveillance Service. The Surveillance capability will retain the default configuration disablement of user2user connectivity within the GPON domain forcing traffic to be handled to/from the external Video Management Server Cluster and Operator Control Platform. This service capability is not expected to carry protocols such as routing protocols (e.g., OSPF, BGP, ISIS etc) or L2 control protocols (e.g., like LAG, RSTP etc) to/from the UNI (customer) ports. Traffic flow bidirectional (media flow upstream and signalling downstream) is only ever between the VMS (Video Management Server)/Operator Control Platform and CCTV cameras and vice versa. The POL solution will provide aspects of redundancy (NNI link (LAG) and controller card protection) but the surveillance solution itself will be required to provide VMS media server storage, IP connectivity and VMS resiliency. NTP protocol transparency will be provided for, so accurate time-stamping is achieved. DHCP can be used for address allocation, DHCP option82 enabled for validation of camera location via a ‘customer ID’. Static IP Address assignment is also supported. MAC address limit of ‘4’ set per UNI (settable).

POL Service: Surveillance (cont)
New Broadcast: Enabled Traffic Forwarding: 1 VLAN used prohibiting user2user comms. QoS Upstream: An untagged interface is specified on the ONT UNI port that is forwarded to the Surveillance Service VLAN ID. A VLAN tagged interface (Display facing) can also be configured if desirable. 10 Mbps bandwidth assigned. An 802.1p bit is force marked a p-bit value of ‘2’, therefore the p-bit value (if the device does send VLAN tags) is irrelevant. The ONT Bridge port has specified a ‘default VLAN’ (pvid) that forwards untagged traffic (from the PC) to the Surveillance Service VLAN. On the downstream, the traffic is untagged and forwarded to the PC. Traffic Forwarding: The VVPLS VLAN connecting the LT cards to the LAG uplink for the Surveillance service is set (with default configuration intention) to prohibit user2user communications. Communication of Access Control Devices should only communicate in a client/server relationship. New Broadcast enablement will also be enabled as communication e2e data flows may be initiated from either side with long durations between requiring ARP in both directions. Secure Forwarding is highly recommended given the public domain these devices are located in physically and the potential for malicious access attempt. This is a configuration option that can be implemented by the customer.

POL Service: Surveillance (cont)
Qos Downstream: Queue 2 Shaper: Committed and Excess date rate component (‘guaranteed’) of 1 Mbps (HD content capable) Filtering: Downstream, 802.1p values must be ‘2’ for the surveillance data or traffic will be dropped. Downstream: Queue 2 (intended for the surveillance signaling traffic): A committed rate component of 1 Mbps. Filtering: The service must send downstream traffic to the customer UNI as 802.1p = ‘2’ or the traffic will be discarded.

9 POL Services: WiFi Access Points

POL Service: WiFi Access Points
WiFi Access Point service designed to host WiFI AP’s via ‘Power over Ethernet’ capability allowing for inter-WiFi-AP roaming The 7360 FX and ONTs for this service concept will have the capabilities and meet the following requirements: Hosts WiFi APs via electrical (RJ45) Ethernet 802.3/Ethernet II or a singular 802.1Q VLAN tag, or untagged framing. 10/100/1000 Mbps ONT interface physical access with a 1G ‘Best Efforts’ bidirectional traffic bandwidth on the UNI. Upstream: Traffic from the network to the user will be prioritised against any other 7360 FX services via ‘strict priority’ precedence via 802.1p. WiFi AP data services will all be treated as ‘best efforts’ (802.1p = ‘0’). Downstream: The service traffic must be sent as 802.1p = ‘0’ towards the UNI or will be discarded. The 7360 FX POLT will contain a singular chassis wide 802.1Q VLAN (defined by the customer) to host the WiFi AP Service. The WiFi AP capability will retain the default configuration disablement of user2user connectivity within the GPON domain forcing traffic to be handled to/from an external Gateway (for instance, the RSP via a BNG). This facilitates in billing all sent and received traffic and any potential lawful intercept requirements. This feature can be disabled if required to facilitate user2user communications. Also allows the Residential Bridge VLAN to be used as opposed to the cross-connect VLAN per UNI like the desktop data services. This service capability is not expected to carry protocols such as routing protocols (e.g., OSPF, BGP, ISIS etc) or L2 control protocols (e.g., like LAG, RSTP etc) to/from the UNI (customer) ports. An ONT variant G-040P-Q providing PoE capability will allow the WiFi APs to be powered independently of an external AC/DC power supply. It is not envisaged that the G-240G-C will host a WiFi AP (due to the lack of PoE capability) but nothing precludes this possibility if separate power feed is able to be provided to the AP (vendor dependent). The PoE settings required to power the WiFi APs via the G-040P-Q are detailed in the Installation and Configuration document which covers the PoE settings per ONT UNI port dependent on the WiFi APs vendor requirements MAC address limit of ‘64’ set per UNI (configurable by the customer if a per AP site would expect to provide connectivity a higher number of devices hence MAC addresses).

POL Service: WiFi AP’s (cont)
Traffic Forwarding: 1 VLAN used, user2user comms optional QoS Upstream: An untagged interface is specified on the ONT UNI port that is forwarded to the WiFi AP Service VLAN ID. A VLAN tagged interface (Display facing) can also be configured if desirable. An 802.1p bit is force marked a p-bit value of ‘0’, therefore the p-bit value (if the AP device does send VLAN tags) is irrelevant and is overwritten. The ONT Bridge port has specified a ‘default VLAN’ (pvid) that forwards untagged traffic (from the PC) to the WiFi AP Service VLAN. On the downstream, the traffic is untagged and forwarded to the PC. Traffic Forwarding: The VVPLS VLAN connecting the LT cards to the LAG uplink for the WiFi AP service is set (with default configuration intention) to prohibit user2user communications. Communication of AP Devices should only communicate in a client/server relationship. New Broadcast enablement will not be enabled by default as communication e2e data flows shouldn’t need to be initiated from the WAN network side. Secure Forwarding is not necessarily appropriate as the devices to connect are not always known like a statically connected device scenario. Upstream: A forced marking of 802.1Q = ‘3’ for all ingress traffic upstream (from the UNI). Queue 3 will be the queue passing the upstream traffic: A ‘committed’ rate totalling 1 Mbps is applied. If a device connected to the UNI is 802.1Q tag capable and is sending 802.1Q frames upstream, the C-VLAN ID can be any tag value and the 802.1p value can also be set to any value as it will be over-written. The C-VLAN ID will be translated to the service C-VLAN ID and the 802.1p bit will be force overwritten to a value of ‘3’.

10 POL Services: Public Announcement/Intercom

POL Service: Public Announcement/Intercom
The Public Announcement/Intercom Capability solution is intended to support an Ethernet/IP based solution The Public Announcement/Intercom Capability solution is intended to support an Ethernet/IP based solution and shall contain the following features and solution options as follows: The topology of this solution is assumed to be both a centralised control architecture point to multipoint connectivity in a client server relationship, and also have the capability of client2client communications (‘intercom room 1’ to ‘intercom room 2’). The service will be comprised of symmetric high priority bandwidth functionally equivalent to a voice solution. Upstream: QoS will be via 802.1p alignment in which the ONT will ‘force mark’ 802.1p = ‘3’ with the solutions VLAN tag (‘l1’ low1 traffic class, assigned to queue 3 in the Ihub VVPLS and ONT/LT queuing also). Downstream: The service traffic must be sent as 802.1p = ‘3’ towards the UNI or it will be discarded. 10/100/1000 Mbps RJ45 interface speed with Power over Ethernet (PoE) which can be enabled with different powering levels on a per port basis. The Installation and Configuration Guide covers the PoE settings per ONT UNI port dependent on the Intercom vendors requirements. The 7360 FX POLT will contain a singular chassis wide 802.1Q C-VLAN ID of the customer’s choice to host the intercom devices. The Public Announcement/Intercom service is expected to host all centralised PA/Intercom Controller platform(s) on the Network side (not the ONT UNI side) of the 7360 FX Platform. The downstream dedicated voice queue will be used. No IPv4-mcast upstream packets supported.

POL Service: Public Announcement/Intercom (cont)
Traffic Forwarding: 1 VLAN used, user2user comms enabled QoS Upstream: An untagged interface is specified on the ONT UNI port that is forwarded to the PA/Intercom Service VLAN ID. A VLAN tagged interface (Device facing) can also be configured if desirable. An 802.1p bit is force marked a p-bit value of ‘3’, therefore the p-bit value (if the PA/Intercom device does send VLAN tags) is irrelevant and is (force) remarked. The ONT Bridge port has specified a ‘default VLAN’ (pvid) that forwards untagged traffic (from the PC) to the WiFi AP Service VLAN. On the downstream, the traffic is untagged and forwarded to the PC. Traffic Forwarding: The VVPLS VLAN connecting the LT cards to the LAG uplink for the Public Announcement/Intercom service will allow user2user communications as it is assumed intercom units will need to communicate amongst themselves in some use cases. Therefore New Broadcast enablement and user2user communications will be enabled as data flows may be initiated from either side with long durations between requiring ARP in both directions. Secure forwarding will also be an optional feature if enhanced security is desirable. QoS Upstream: • A forced marking of 802.1Q = ‘3’ for all ingress traffic upstream (from the UNI). • Queue 3 will be the queue passing the upstream traffic: A ‘committed’ rate totaling 1 Mbps is applied. If a device connected to the UNI is 802.1Q tag capable and is sending 802.1Q frames upstream, the C-VLAN ID can be any tag value and the 802.1p value can also be set to any value as it will be over-written. The C-VLAN ID will be translated to the service C-VLAN ID and the 802.1p bit will be force overwritten to a value of ‘3’.

POL Service: Public Announcement/Intercom (cont)
Qos Downstream: Queue 3 Shaper: Committed rate component (‘guaranteed’) of 1 Mbps bidirectional Filtering: Downstream, 802.1p values must be ‘3’ for the surveillance data or traffic will be dropped. Downstream: All traffic will be forwarded via Queue 3: A committed rate of 1 Mbps will be assigned. The data stream must be C-VLAN ID marked as per the customer defined service C-VLAN ID. Filtering: The service must send downstream traffic to the customer UNI as 802.1p = ‘3’ or the traffic will be discarded.

11 POL Services: Modes of Operation

POL Services: 5 Modes of Operation
How does an Operator know how to implement what VLAN ‘flag’ arguments and when? Secure Forwarding, Downstream Broadcast, User-User Communications, Multicast Upstream Allow, MAC Movement Allow, VVPS/VPLS, Cross-Connect/Residential Bridge VLANs…what does the customer use and when??? ‘5 Modes of Operation’… guides the operator on the settings required per use-case.

Mode 1: ‘Switch Emulation’
The customer wants to create a service where user-user is a requirement to be facilitated within the OLT/ONT domain to save traffic forwarded outside of the OLT/ONT domain unnecessarily. IPv4/6 multicast packets must also be allowed. These datagram’s are typically needed to provide Bonjour/zeroconf services and printing jobs. In addition to this service description: The Customer may optionally also enable DHCP Option82 or may enable 802.1x. for authentication processes The Customer does not require the IP anti-spoofing feature (called Secure Forwarding in Nokia terminology) to all UNI ports All settings above are fully interoperable in any combination Power Over Ethernet (PoE) may optionally be enabled with any PoE class assigned per service The Customer picks one upstream and one downstream speed rate from the selections offered. The customer is informed about the internal VLAN assignment required per UNI port and the management of these VLAN IDs and the potential for VLAN-ID exhaustion in networks with beyond 4000 UNIs. The customer is free to modify the MAC age timers if desirable.

Mode 2: ‘Restricted User-user’
The customer wants to create a service where user-user is a requirement to be facilitated within the OLT/ONT domain to save traffic forwarded outside of the OLT/ONT domain unnecessarily. The customer has limited ability to use Proxy ARP or L3 VPN routing to facilitate user-user, and may also not want to consume ‘internal' VLAN-IDs as is required for Mode 1 (Switch Emulation), especially for large networks approaching 4000 UNI endpoints. IPv4/6 multicast packets are not required to be passed within this service, and the customer understands that this must not be allowed to be enabled in future with this service type and combination. This Mode 2 capability is not available for the following services (as the capability combination is not envisaged as required): Security Access Control, Surveillance and Digital Signage, but available for all other services. In addition to this service description: The Customer may optionally enable DHCP Option82 or may enable 802.1x. Power Over Ethernet (PoE) may optionally be enabled with any PoE class assigned per service The Customer must enable the IP anti-spoofing feature (called Secure Forwarding in Nokia terminology) to this service. The customer also understands that ‘user-user’ (within the OLT/ONT) cannot be enabled at a later date on this service type combination, therefore the core routing, or proxy ARP performs this function permanently. All settings described as ‘may’ above are fully interoperable in any combination The customer is free to modify the MAC age timers if desirable. MAC Move allow is also a manual setting (via the 5520 AMS GUI) that applies optionally to the WiFi AP service for Mode 2 Operation.

Mode 3: ‘Forced Forwarding’
The customer wants to create a service where user-user is not required to be facilitated within the OLT/ONT domain, as this functionality will instead be achieved via L3 VPN or Proxy ARP at the Core Switch/router. It is assumed Cloud Services, or Centralized Application control will be the predominant broker of user-user connectivity so all user-user traffic is externalized from the OLT/ONT domain. Therefore all ONT UNIs are (left) in a ‘split-horizon’ function within the OLT/ONT domain therefore only forward via the uplink NNI, rather than direct to adjacent UNI ports. This Mode 3 capability is available for all services. In addition to this service description: The Customer may optionally enable DHCP Option82 or 802.1x. The Customer does not require the IP anti-spoofing feature (called Secure Forwarding in Nokia terminology) for this service The customer does require the enabling of e2e forwarding of multicast frames to pass for Bonjour/zeroconf services that are also used for their vendor’s printer services. The Customer picks one upstream and one downstream speed rate from the rate selections offered in the table below. The Customer must not enable ‘user-user’ within the OLT and understands that ‘user-user’ (within the OLT/ONT) cannot be enabled at a later date on this service type combination, therefore the core routing, or proxy ARP performs this function permanently. The customer is free to modify the MAC age timers if desirable. MAC Move allow is also a manual setting (via the 5520 AMS GUI) that applies optionally to the WiFi AP service for Mode 3 Operation.

Mode 4: ‘Secure Forced Forwarding’
The customer wants to create a service where user-user is not required to be facilitated within the OLT/ONT domain, as this functionality will instead be achieved via L3 VPN or Proxy ARP at the Core Switch/router. It is assumed Cloud Services or Centralized Application control will be the predominant broker of user-user connectivity so all user-user is externalized from the OLT/ONT domain. Therefore all ONT UNIs are (left) in a ‘split-horizon’ function within the OLT/ONT domain therefore only forward via the uplink NNI, rather than direct to adjacent UNI ports. The customer wants IP anti-spoofing on all UNI’s supporting this service. This Mode 4 capability is available for all services. In addition to this service description: • The Customer may optionally enable DHCP Option82 or 802.1x. • The Customer does enable the IP anti-spoofing feature (called Secure Forwarding in Nokia terminology) to the service • The customer does require the enabling of e2e forwarding of multicast frames to pass for Bonjour/zeroconf services that are also used for their vendor’s printer services. • All settings above are fully interoperable in any combination • The Customer picks one upstream and one downstream speed rate from the rate selections offered in the table below. • The Customer must not enable ‘user-user’ within the OLT and understands that ‘user-user’ (within the OLT/ONT) cannot be enabled at a later date on this service type combination, therefore the core routing, or proxy ARP performs this function permanently. • The customer is free to modify the MAC age timers if desirable. • MAC Move allow is also a manual setting (via the 5520 AMS GUI) that applies optionally to the WiFi AP service for Mode 4 Operation.

Mode 5: ‘Secure Switch Emulation’
The customer wants to create a service where user-user is a requirement to be facilitated within the OLT/ONT domain to save traffic forwarded outside of the OLT/ONT domain unnecessarily. IPv4/6 multicast packets must also be allowed. These datagram’s are typically needed to provide Bonjour/zeroconf services and printing jobs. This Mode 5 capability is not available for the following services: Surveillance, Security Access Control, Public Announcement, IP Voice, Digital Signage, WiFiAP, Public Announcement or HSI services. Mode 5 capability is available for the FTT Desktop Data service. In addition to this service description: The Customer may optionally also enable DHCP Option82 or may enable 802.1x. for authentication processes The Customer does enable the IP anti-spoofing feature (called Secure Forwarding in Nokia terminology) to all UNI ports All settings above are fully interoperable in any combination Power Over Ethernet (PoE) may optionally be enabled with any PoE class assigned per service The Customer picks one upstream and one downstream speed rate from the selections offered. The customer is informed about the internal VLAN assignment required per UNI port and the management of these VLAN IDs and the potential for VLAN-ID exhaustion in networks with beyond 4000 UNIs. The customer is free to modify the MAC age timers if desirable.

Mode Design Examples The ‘FTT_DATA_VPLS’ mode template options are as displayed (Design Document extract)

Mode Design Examples (continued)

12 POL Services: Filters

POL Service: Security Filtering
The 7360FX/ONT portfolio has extensive traffic conditioning and filtration processes, many not used in POL. As an FYI: DSCP to 802.1p maps. Aligns DSCP datagram markings to 802.1p (layer 2 markers) if required 802.1p marking drop: Achieved via the current QOS policies for POL. Non compliant .1p markings can be filtered and dropped if desirable MAC Address Filters: Pass/drop based on a full MAC address match, OUI, or a MAC address range Any bespoke filtering requirements should be fed back to Nokia via the local project representative

POL Service: Security Filtering (continued)
An example below is MAC address range of 00:30:f9:12:00:00 to 00:30:f9:12:ff:ff is passed, all else is dropped. Apply the policy ‘test’ to the UNI bridge port to screen traffic. A POL customer used this for a CCTV camera install with a known MAC range so no other devices could gain connectivity via the UNI ports hosting the CCTV devices

13 Perform Lab (module 4)

End of Module 4

Passive Optical LAN Training: Module 4: Services Description

Similar presentations

Presentation on theme: "Passive Optical LAN Training: Module 4: Services Description"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Passive Optical LAN Training: Module 4: Services Description

Similar presentations

Presentation on theme: "Passive Optical LAN Training: Module 4: Services Description"— Presentation transcript:

Similar presentations

About project

Feedback