76 8670 50180a 8630 smart router and 8660 smart router FP7 0 interface configuration guide

8600 Smart Routers FP7.0 Interface Configuration Guide 76.8670-50180A 12.05.2015 Document Information Revision History Document No Date Description of Changes 76.8670-50180A 12.05.2015 Added support of Ethernet MAC switching on LAG in 5.2 ELC1 Interfaces Functionality Changes applied in: • 11.3.2 Interface Operation Mode • VLAN and QinQ Interface Statistics This manual documents the following network elements 8620 Smart Router 8630 Smart Router 8660 Smart Router © 2015 Coriant All rights reserved This manual is protected by U.S and international copyright laws, conventions and treaties Your right to use this manual is subject to limitations and restrictions imposed by applicable licenses and copyright laws Unauthorized reproduction, modification, distribution, display or other use of this manual may result in criminal and civil penalties The specifications and information regarding the products in this manual are subject to change without notice All statements, information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind, express or implied Users must take full responsibility for their application of any products Adobe ® Reader ® are registered trademarks of Adobe Systems Incorporated in the United States and/or other countries 8600 Smart Routers FP7.0 Interface Configuration Guide 76.8670-50180A © 2015 Coriant Document Information Terms and Abbreviations 76.8670-50180A © 2015 Coriant Term Explanation AAL ATM Adaptation Layer AC Attachment Circuit ACFC Address and Control Field Compression AIS Alarm Indication Signal APS Automatic Protection Switching APSG Automatic Protection Switch Group ATM Asynchronous Transfer Mode BA Bandwidth Allocation BE Best Effort BER Bit Error Ratio BFD Bidirectional Forwarding Detection BIF Backplane Interface links CAC Connection Admission Control CBR Constant Bit Rate CDC Control and DC Power Card CID Context Identifier CIF Cluster Interface links CESoPSN Circuit Emulation Service over Packet Switched Network cHDLC Cisco High-Level Data Link Control CIR Committed Information Rate CLI Command Line Interface CPE Customer-Premises Equipment CRC Cyclic Redundancy Check DEG Degraded DLCI Data Link Connection Identifier DSLAM Digital Subscriber Line Access Multiplexer EDC Error Detection Code ELC1 Ethernet Line Card ELP Ethernet Link Protection ERDI Enhanced Remote Defect Indicator ESF Extended Super Frame Ethernet OAM Operations, Administration, and Maintenance according to IEEE802.1ag 8600 Smart Routers FP7.0 Interface Configuration Guide Document Information FCS Frame Check Sequence FRPVC Frame Relay Permanent Virtual Connection HDLC High-Level Data Link Control IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IFC Interface Module Concentrator is the line card baseboard IFC line card The IFC line card is used in 8630 Smart Router and 8660 Smart Router and consists of an IFC and up to two IFMs There are two types of IFC line cards: IFC1 and IFC2 IFM Interface Module IMA Inverse Multiplexing for ATM IP Internet Protocol IPCP IP Network Control Protocol of the PPP IPIF IP Interface IPHC IP Header Compression IS-IS Intermediate System to Intermediate System (Interior Gateway Protocol) LAG Link Aggregation LAN Local Area Network LCP Link Control Protocol Line card Of type IFC or ELC1 LLC Logical Link Control LMI Local Management Interface LOF Loss Of Frame LOM Loss Of H4 Multiframe LOP Loss Of Pointer MAC Media Access Control MC-MLPPP Multiclass MLPPP MGMT Management Port MLPPP Multilink PPP MPLS Multiprotocol Label Switching A switching method that forwards IP traffic using a label MPLSCP MPLS Network Control Protocol of the PPP MRU Maximum Receive Unit MRRU Maximum Received Reconstructed Unit MS Multiplex Section MS Multiservice (Interface Module) MSPG Multiplex Section Protection Group MSP 1+1 Multiplex Section Trail Protection 1+1 8600 Smart Routers FP7.0 Interface Configuration Guide 76.8670-50180A © 2015 Coriant Document Information 76.8670-50180A © 2015 Coriant MTU Maximum Transmission Unit MuxCP Multiplexed Control Protocol NCP Network Control Protocol NE Network Element NLPID Network Layer Protocol Identifier NNI Network-to-Network Interface NRT Non-Real Time NTP Network Time Protocol OSINLCP OSI Network Layer Control Protocol P12s Framed 2.048 kbps according to G.704 and G.706 P12x Unframed 2.048 kbps according to G.703 PDH Plesiochronous Digital Hierarchy PFC Protocol Field Compression PFF Protocol Field Flag PGF Protection Group Failed PID Protocol ID PNNI Private Network to Node Interface POS Packet over SDH/SONET PPP Point-to-Point Protocol PPPMux PPP Multiplexing PPPMuxCP PPP Multiplexed Control Protocol PWE3 Pseudowire Emulation Edge to Edge QoS Quality of Service RAI Remote Alarm Indicator RDI Remote Defect Indicator RT Real Time SAToP Structure-Agnostic Time Division Multiplexing over Packet SDH Synchronous Digital Hierarchy SF Super Frame SFP Small Form factor Pluggable SLARP Serial Line Address Resolution Protocol SLM Signal Label Mismatch SNAP Subnetwork Access Protocol SSD Server Signal Degraded SSF Server Signal Fail TDM Time Division Multiplexing TIM Trace Identifier Mismatch 8600 Smart Routers FP7.0 Interface Configuration Guide Document Information TLP Transmission Layer Port TTI Trail Trace Identifier UBR Unspecified Bit Rate UDP User Datagram Protocol UNEQ Unequipped UNI User Network Interface VBR Variable Bit Rate VC ATM Virtual Channel VCC Virtual Channel Connection VCCV Virtual Circuit Connectivity Verification VCI Virtual Channel Identifier VCL Virtual Channel Link VLAN Virtual LAN VP Virtual Path VPC Virtual Path Connection VPI Virtual Path Identifier VPL Virtual Path Link VoIP Voice over IP VSI Virtual Switching Instance XC Cross-Connection 8600 Smart Routers FP7.0 Interface Configuration Guide 76.8670-50180A © 2015 Coriant Table of Contents Table of Contents About This Manual 11 Objectives 11 Audience 11 8600 Smart Routers Technical Documentation .11 Interface Numbering Conventions 15 Document Conventions 15 Documentation Feedback 15 8600 Smart Routers Discontinued Products 16 Overview 17 1.1 1.2 1.3 STM-N/OC-N POS Interface Modules 31 2.1 2.2 2.3 ETSI and ANSI Mode 17 8620 Smart Router 18 1.2.1 Supported IFMs 18 1.2.2 IFM Combinations 19 8630 Smart Router and 8660 Smart Router 21 1.3.1 General Line Card Architecture 21 1.3.2 IFC Line Card 22 1.3.3 Ethernet Line Card (ELC1) 27 8xSTM-1/OC-3 POS Interface Module 31 2.1.1 Overview 31 2.1.2 Layer Configuration 31 4xSTM-4/OC-12 POS Interface Module 32 2.2.1 Overview 32 2.2.2 Layer Configuration 32 1xSTM-16/OC-48 POS Interface Module 33 2.3.1 Overview 33 2.3.2 Layer Configuration 33 Ethernet Interface Modules 34 3.1 76.8670-50180A © 2015 Coriant Regular Ethernet IFMs 34 8600 Smart Routers FP7.0 Interface Configuration Guide Table of Contents 3.2 3.3 ATM and Multiservice Interface Modules 48 4.1 4.2 4.3 4.4 4xSTM-1/OC-3 ATM Interface Module 48 4.1.1 Overview 48 4.1.2 Limitations and Restrictions in 4xSTM-1/OC-3 ATM IFM 49 4.1.3 Layer Configuration 50 1xchSTM-1/chOC-3 Multiservice Interface Module 51 4.2.1 Overview 51 4.2.2 Multiservice Interface 53 4.2.3 Limitations and Restrictions in 1xchSTM-1/chOC-3 MS IFM 55 4.2.4 Layer Configuration 55 4.2.5 TDM Performance Monitoring 56 4xchSTM-1/chOC-3 Multiservice Interface Module 56 4.3.1 Overview 56 4.3.2 Multiservice Interface 59 4.3.3 Limitations and Restrictions in 4xchSTM-1/chOC-3 MS IFM 61 4.3.4 Layer Configuration 62 4.3.5 TDM Performance Monitoring 62 24xchE1/chT1 Multiservice Interface Module 63 4.4.1 Overview 63 4.4.2 Multiservice Interface 64 4.4.3 Limitations and Restrictions 66 4.4.4 Layer Configuration 66 4.4.5 TDM Performance Monitoring 67 ELC1 (2x10GBASE-R/12x1000BASE-X ) Interfaces 68 5.1 5.2 3.1.1 8x10/100BASE-TX Ethernet Interface Module (Electrical Fast Ethernet) 34 3.1.2 8x100BASE-X Ethernet Interface Module (SFP) 35 3.1.3 2x1000BASE-X Ethernet Interface Module (SFP) 35 High Capacity Ethernet IFMs 36 3.2.1 8x1000BASE-X Ethernet Interface Module (SFP) 36 3.2.2 2+6x10/100/1000BASE-COMBO Ethernet Interface Module (SFP + Electrical) 37 3.2.3 8x10/100/1000BASE-TX R2 Ethernet Interface Module 38 3.2.4 8x100/1000BASE-X R2 Ethernet Interface Module 40 3.2.5 1x10GBASE-R R2 Ethernet Interface Module 41 3.2.6 Adjustable Forwarding Capacity 42 Management Port (MGMT) 46 ELC1 Forwarding Capacity 69 ELC1 Interfaces Functionality 71 5.2.1 Physical Ethernet Interface 71 5.2.2 Ethernet Layer Functions 73 5.2.3 Network Services 74 5.2.4 Scalability 74 5.2.5 Ethernet Layer Configuration Options 74 Fault Management Operation and Configuration 76 8600 Smart Routers FP7.0 Interface Configuration Guide 76.8670-50180A © 2015 Coriant Table of Contents 6.1 MSP/APS Operation and Configuration 78 7.1 7.2 7.3 7.4 Overview 78 7.1.1 1+1 Unidirectional Mode 78 7.1.2 1+1 Bidirectional Mode 79 Configuration Rules 80 Configuring Protected Interfaces 82 Fault Monitoring on Protected Interfaces 82 Performance Monitoring 84 8.1 TDM Fault Management 76 6.1.1 Principles 76 6.1.2 Fault Suppression 77 TDM Performance Monitoring 84 8.1.1 G.826 Performance Monitoring 84 8.1.2 GR-253/GR-820 Performance Monitoring 85 ANSI Loopback Operations 88 9.1 DS1 Loopback 88 9.1.1 Loopback Operation 88 9.1.2 Equipment Loopback Operation 88 9.1.3 Invoking a Remote Loopback 88 9.1.4 Remote Loopback Methods 88 9.1.5 Loopback Example in SAToP Application 89 9.1.6 Loopback Example in CESoPSN, and Multiservice Applications 90 10 References 92 11 Interface Configuration Examples 95 11.1 All Interfaces 96 11.1.1 Basic Configuration 96 11.1.2 Checking Interface Configuration Status and Basic Troubleshooting 97 11.2 Packet Over SDH (POS) IFMs 98 11.2.1 Configuring Physical Layer Interface 98 11.2.2 Configuring RS and VC-4 Path Trace Monitoring 99 11.2.3 Configuring PPP Layer Configuration 99 11.2.4 Configuring Fault Monitoring and Reporting 100 11.3 Ethernet Interfaces 102 11.3.1 Ethernet Basic Configuration 102 11.3.2 Interface Operation Mode 103 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide Table of Contents 11.4 11.5 11.6 11.7 11.3.3 VLAN Management 104 11.3.4 High Capacity Ethernet IFMs Specific Configuration 105 11.3.5 CDC MGMT Port 109 4xSTM-1/OC-3 ATM IFM 110 11.4.1 Starting the Configuration 110 11.4.2 Configuring Physical Layer Interface .110 11.4.3 Configuring RS/Section and VC-4/STS SPE Path Trace Monitoring 111 11.4.4 Configuring Fault Monitoring and Reporting 111 1xchSTM-1/chOC-3 and 4xchSTM-1/chOC-3 Multiservice IFMs 111 11.5.1 Starting the Configuration 111 11.5.2 Configuring Physical Layer Interface .111 11.5.3 Configuring RS/Section and VC-4/STS SPE Path Trace Monitoring 111 11.5.4 Configuring VC-12/VT1.5 Path Trace Monitoring 111 11.5.5 Configuring P12s Layer for ATM and Frame Relay 112 11.5.6 Configuring DS1 Layer for ATM .113 11.5.7 Configuring PPP and MLPPP 113 11.5.8 Configuring P12s for Cisco HDLC 117 11.5.9 Configuring Fault Monitoring and Reporting 117 24xchE1/chT1 Multiservice IFM .118 11.6.1 Starting Configuration 118 11.6.2 Configuring E1/T1 Physical Layer Interface 118 11.6.3 Configuring P12s Layer for ATM .119 11.6.4 Configuring DS1 Layer for ATM .119 11.6.5 Configuring P12s/DS1 for HDLC 119 11.6.6 Configuring P12s/DS1 for Cisco HDLC 120 11.6.7 Configuring P12s/DS1 for PPP and MLPPP 120 11.6.8 Configuring ANSI Remote Loopbacks 126 11.6.9 Configuring Fault Monitoring and Reporting 126 11.6.10 PPP IP Interworking Configuration 127 MSP/APS Configuration 129 11.7.1 Creating MSP1+1/APS1+1 Unidirectional Protection Group 130 11.7.2 Creating MSP1+1/APS1+1 Unidirectional Protection Group – Non-Standard Mode 130 11.7.3 Deleting MSP1+1/APS1+1 Protection Group 131 11.7.4 External Switchover Operations 131 11.7.5 Creating MSP1+1/APS1+1 Bidirectional Protection Group 132 11.7.6 Investigating Protection Status 132 Layer Descriptions 134 SDH & SONET Layers 134 PDH Layers 144 Ethernet Layers 147 Port Protocols 156 Fault Management 179 8600 Smart Routers FP7.0 Interface Configuration Guide 10 76.8670-50180A © 2015 Coriant Layer Descriptions MLPPP Port Configuration P12s/E1 Mode DS1 Mode Number of configurable timeslot groups 1 Available timeslots for user payload 31 31 (unframed) 24 Granularity of TDM timeslot group Nx64k Nx64k (unframed) Nx64k Available bandwidth for user payload 1984 kbps 2048 kbps (unframed) 1536 kbps 1544 kbps (unframed) Payload scrambling no no PDH interface usage configuration terminated (framed) connected (unframed) terminated (framed) connected (unframed) Timeslot group usage configuration terminated (framed) terminated (framed) Port protocol ppp ppp MLPPP Scalability 1xchSTM1/chOC-3 4xchSTM1/chOC-3 24xchE1/chT1 Maximum number of MLPPP links per IFM 63/84 168 24 Maximum number of MLPPP groups per IFM 63/84 84 24 Maximum number of PPP links per MLPPP group 16 16 16 MLPPP Differential Delay MLPPP delay difference between the member links leads to additional delay to all frames transmitted over the MLPPP group Large enough delay difference causes frame loss as possible fragments of the frames are eventually timed out and discarded in the receiver side reassembly buffer MLPPP differential delay measurement provides a tool for link differential delay monitoring between the MLPPP group links The maximum differential delay (maximum tolerated delay between the fragments of a frame) configuration can be used to limit the maximum delay of an MLPPP group A frame can be sent further only when all fragments have been received, therefore the slowest path defines the overall delay There are two ways to measure MLPPP differential delay: • Using explicit test frames • Statistical analysis of received frame, i.e arrival time and sequence numbers The 8600 system uses frame based method to measure the MLPPP differential delay Explicit test frames are used as PPP Echo Request and Echo Reply [RFC1661] payload A one-way differential delay of links is measured using the hardware based timestamps included in Echo-packets In addition to one-way differential delay timestamps, Round Trip Time (RTT) is also measured and Network Time Protocol (NTP), Real Time Clock (RTC) timestamps can be used as an additional information There are several adjustable parameters related to MLPPP differential delay measurements: 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide 165 Layer Descriptions • Maximum one-way differential delay in microseconds (default 25000 µs), which must be equally set in both sides • Thresholds for action when exceeding values are detected • Execution action, which is based on the transmitter side hardware timestamps: • Dropping a link (default) exceeding one-way differential delay • Raising fault • Threshold for link back to use, which sets the link back up into use, or sets fault off MLPPP Differential Delay Monitoring As the measurement of one-way differential delay is based on hardware timestamps, it is quite accurate Nevertheless, when additional traffic is sent through an MLPPP group, the transmitter and receiver queuing may add additional delay to the measurement frames This creates small variance to the measurement results However the effect is considered as normal in frame based measurements and must be taken into account when setting the maximum one-way differential delay values In general, configuring 1200 µs restore value below the preferred target value is large enough tolerance to prevent frames being dropped due to large differential delay and still being capable to detect delay variation in one or several links of the MLPPP group Full performance monitoring and accurate calculations of one-way differential delay can be achieved only when both ends of the link support hardware timestamps Moreover additional performance information can be monitored, if NTP is configured When unidirectional protection is used and transmit and receive are on different ports on the NE, receiver side one-way differential delay performance and hardware RTT information is not available MC-MLPPP Layer Configuration Multiclass MLPPP (MC-MLPPP) is used to decrease the latency observed by delay sensitive high priority frames going through MLPPP group This can be achieved by allowing high priority frames to interrupt the low priority frame transmission Without MC-MLPPP, the low priority frames are always sent as a whole to the line before a high priority frame can be sent Network Applications MC-MLPPP enables fragmentation of data frames of different priorities into multiple classes in an MLPPP group It enables a transmission of high priority frames between fragments of lower priority frames MC-MLPPP ensures the delivery of high priority, delay-sensitive traffic, such as voice and video in the proper sequence by creating separate transmit and receive context for every multilink class in the multilink group Transmit and receive contexts contain separate sequence numbers and all other statistics pertaining to each multilink class The data frames of each multilink class are encapsulated in an MLPPP header The sequence numbers of each of the classes are also embedded within the header before transmission The receiving peer processes each class independently and uses the sequence number in the MLPPP header to internally reorder and reassemble frames in the desired sequence 8600 Smart Routers FP7.0 Interface Configuration Guide 166 76.8670-50180A © 2015 Coriant Layer Descriptions MC-MLPPP advantage will not be applicable in cases where all traffic belongs to the same DiffServ traffic class or when fragmentation is not enabled Due to the suspension of low priority frames by high priority frame, MC-MLPPP process increases the latency of low priority traffic MC-MLPPP with interleaving is not supported since MC-MLPPP already takes care of suspending lower priority frames for transmitting higher priority frames Hence, interleaving with multiclass does not give any additional advantages Detailed Operation LCP Negotiation Local and remote peers receive fragments with the format given by the code number, maximum number of suspendable classes as defined in [RFC2686] for multilink header format LCP option Once LCP negotiation is successfully between peers, then peers transmit all subsequent multilink frames with negotiated class values on all links of the group When Address and Control Field Compression (ACFC) is enabled , the PPP header would exclude the address and control field When Protocol Field Compression (PFC) is enabled, the leading zeroes in PID would be excluded The 8600 system by default disables ACFC, while PFC is enabled The number of multilink classes in transmit direction can be configured by the user The actual number of used multilink classes is based on the negotiation between local and remote node like the following table shows Explicit multilink class numbers or QoS mappings to multilink classes are not negotiated Local Receiver Configuration Event from Peer Response to Peer Multiclass is enabled, classes (suspension levels) configured Request for more than classes Reject requested classes and inform the supported maximum number of classes as Request for classes or less than classes Accept the requested classes Peer rejects multiclass Negotiation is failed and fault is raised Request for classes or less than classes Reject multiclass Multiclass is disabled Frame Structure and Processing MC-MLPPP Frame Structure MC-MLPPP frame format has two options with 12 and 24 bits sequence number By default, the sequence field is 24 bits long, but can be negotiated to be 12 bits 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide 167 Layer Descriptions Fig 31 MC-MLPPP MP Header QoS Mapping Consideration The 8600 system supports a maximum of multilink transmit classes (suspension levels) Maximum up to multilink classes can be enabled at the same time Depending on the networking conditions DiffServ traffic classes can be mapped to multilink classes Because the actual number of multilink classes is a result of a negotiation with peer node the system allows to use different mapping depending on the result of the negotiation This is configured using Group Class parameter Group Class is configured separately for cases where 2, and multilink classes are used A user can map CS7 and EF independently to any multilink class, but there is a restriction that all the AF and BE shall be mapped to the same multilink class Group class concept provides a flexibility and interoperability with other vendors which may have different QoS to multilink class mapping schemes The mappings is local to the node where it is configured and Class field in the MC-MLPPP frame is just informative for a receiver When mappings are not configured explicitly, default mappings are used as shown in the following table Group Class QoS Queue Multilink Class (Suspension Level) CS7, EF, AF1–4, BE CS7, EF AF1–4, BE CS7 EF AF1–4, BE CS7 EF AF1–4, BE 8600 Smart Routers FP7.0 Interface Configuration Guide 168 76.8670-50180A © 2015 Coriant Layer Descriptions The following figure shows the default mapping when multilink classes are negotiated (Group Class = 4) Fig 32 MC-MLPPP QoS to Suspension Levels Mapping Latency Consideration The frame size and traffic rates play an important role in the latency improvement of the high priority frame when sent together with the low priority frames Without MC-MLPPP, high priority frames have to wait for the whole low priority frame to be transmitted over the link The latency improvement with MC-MLPPP is more evident, when low priority frames are interrupted frequently by the high priority frames 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide 169 Layer Descriptions Fig 33 MLPPP and MC-MLPPP Latency Fig 33 depicts two cases of latency scenario The example assumes an MLPPP group with an E1 member link of 1920 kbps bandwidth capacity and fragmentation size of 375 bytes Case 1: MLPPP with fragmentation enabled: Without MC-MLPPP, all fragments of the BE frame would be transmitted without considering high priority CS7 frame The CS7 frame would have to wait for the whole BE fragments to be transmitted Thus the latency experienced by high priority traffic Tla, i.e the total time taken to transfer CS7 queue frame can be calculated as following: Tla = Tbe + Tcs7 Where: • Tbe is the time taken to transfer the whole fragmented BE frame In this example Tbe = (4*375 *8 bits)/1920 kbps = 6.250 ms • Tcs7 is the time taken to transfer CS7 subframe Tcs7 = (64*8 bits)/1920 kbps = 0.267 ms In this case example, high priority traffic would experience a latency of 6.517 ms Case 2: MC-MLPPP with fragmentation enabled: Enabling MC-MLPPP allows interruption of low priority traffic (BE frame) fragments by high priority traffic as illustrated in Fig 33 After CS7 frame is transmitted, then transmission of BE fragments is resumed The latency experienced by high priority traffic Tla, when using MC-MLPPP can be calculated as following: Tla = Tfbe + Tcs7 Where: • Tfbe is the time taken to transfer one BE fragment Tfbe = (375*8 bits)/1920 kbps = 1.560 ms 8600 Smart Routers FP7.0 Interface Configuration Guide 170 76.8670-50180A © 2015 Coriant Layer Descriptions The latency of high priority traffic when MC-MLPPP is enabled in this example is 1.827 ms However, the processing delay (typically less than ms) is also present and thus theoretical delays will not be achieved exactly Configuration Options The available configuration options required for MC-MLPPP are presented below MS IFMs MC-MLPPP Configuration 1xchSTM-1/chOC-3 4xchSTM-1/chOC-3 24xchE1/chT1 TX multilink traffic classes 1–2 1–4 1–4 RX multilink traffic classes (fixed) (fixed) (fixed) Class-QoS-Mapping (Group) 2–4 2–4 Class-QoS-Mapping (QoS granularity) CS7, EF, AF-BE CS7, EF, AF-BE CS7, EF, AF-BE Class-QoS-Mapping (Class) 0–1 0–3 0–3 MC-MLPPP and PPPMux Coexistence In some network applications, there might be a need for simultaneous use of MC-MLPPP and PPPMux where the usages of bandwidth and latency considerations are both important MC-MLPPP is generally used to decrease the latency for high priority frames as it allows interrupting the transmission of low priority frames for the benefit of high priority traffic and PPPMux is used for efficient bandwidth usage as it decreases the frame header overhead Frames arriving first to the multiplexing process must wait for other high priority frames adding to the latency Selecting PPPMux configuration parameters (PPPMux Transmitter) appropriately to reduce the overhead for higher priority frames) and enabling multiclass with suitable MLPPP fragment size ensures that further latency is not introduced due to multiplexing frames MC-MLPPP is mainly focused to reduce the latency of high priority frames The latency of low priority frames is increased because of high priority frames interruption Consider the following configuration when PPPMux is only enabled on an MLPPP group with bandwidth of 1920 kbps (E1 link) and fragmentation size of 375 bytes • Transmit timer = ms • Maximum frame-size = 256 bytes • Subframe count = • Subframe size = 64 bytes Assuming that CS7 traffic (frame size of 64 bytes) is received at frame/ms The configuration above ensures that every PPP multiplexed frame will consist of four CS7 subframe The first CS7 subframe arriving, will have to wait Tw = ms for the next three CS7 subframe The size of BE frame in this example is 1500 bytes 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide 171 Layer Descriptions Fig 34 PPPMux and MC-MLPPP Latency • Case 1: When PPPMux is enabled with MLPPP In this case, latency experienced by high priority traffic Tlamux, i.e the worst case delay to transmit a PPP multiplexed frame can be calculated as following: Tlamux = Tw + Tmux + Tbe Where: • Tw is the waiting time for the first CS7 frame before the remaining frames arrived, ms in this example • Tmux is the time taken to transmit the PPP multiplexed frame over the link Tmux = (4*64*8 bits)/1920 kbps = 1.06 ms • Tbe is the time taken to transmit the whole BE frame Tbe = (4*375*8 bits)/1920 kbps = 6.25 ms In this case example, a latency of PPP multiplexed frame is 10.31 ms • Case 2: When PPPMux is enabled with MC-MLPPP Tlamux = Tw + Tmux + Tfbe Where: • Tfbe is the time taken to transfer one BE fragment Tfbe = (375*8 bits)/1920 kbps = 1.56 ms The latency of PPP multiplexed frame when MC-MLPPP is enabled in this example is 5.62 ms However, the processing delay (typically less than ms) is also present and thus theoretical delays will not be achieved exactly 8600 Smart Routers FP7.0 Interface Configuration Guide 172 76.8670-50180A © 2015 Coriant Layer Descriptions Fig 35 PPPMux and Multi Link Classes There are only two multilink classes when MC-MLPPP is enabled with PPPMux Although, multiclass negotiation can happen with more than classes, the system enforces traffic to use two multilink classes; EF and CS7 are placed to the same multilink class because preceding PPPmux function has already multiplexed CS7 and EF frames to the same PPPmux packet Rest of the traffic classes are enforced to another multilink class In Fig 35, when PPPMux is enabled with multiclass (negotiated with classes), CS7 and EF are mapped to multilink class Whereas, AF4, AF3, AF2, AF1 and BE are mapped to multilink class CS7 and EF are multiplexed to the same frame, thus it is not meaningful to allow CS7 suspend EF and therefore they must be in the same class 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide 173 Layer Descriptions Ethernet PWE3 PPP Interworking Function Ethernet PWE3 PPP interworking function is used when IP over PPP routed mode CPE (Customer-Premises Equipment) is connected to the 24xchE1/chT1 MS IFM and Ethernet PWE3 services are used on the PSN side On the AC side, a PPP link is terminated when IPv4 is negotiated by the PPP NCP On the PSN side Ethernet PWE3 raw mode is terminated to a logical Ethernet interface located in the 24xchE1/chT1 MS IFM IP frames are forwarded between the logical Ethernet and PPP interfaces as follows: • In PSN to the AC direction, the Ethernet destination MAC address and Ethernet type (0x0800) are checked before an IPv4 packet is forwarded to the PPP link • In AC to the PSN direction, all IPv4 packets from a PPP link are encapsulated to Ethernet IP traffic forwarding towards the Ethernet network requires existence of IP address to Ethernet MAC mapping This can be achieved either by a user configurable Ethernet destination MAC address (static ARP), or dynamically learned through ARP An Ethernet packet is further encapsulated to Ethernet PWE3 raw mode packet(s) IPv4 multicast packets are multicasted over Ethernet shared media The selection between static and dynamic ARP modes is determined by the Ethernet destination MAC address configuration as follows: • No ARP request will be triggered in presence of a configured destination MAC address on Ethernet PPP interworking interface • ARP request will be triggered if the destination MAC address is not configured and the PWE3 circuit is up The following topology provides an illustration of interworking function (IPIW) Fig 36 Ethernet PWE3 PPP Interworking 8600 Smart Routers FP7.0 Interface Configuration Guide 174 76.8670-50180A © 2015 Coriant Layer Descriptions Static ARP In static mode, the remote end router (PE) must have a static ARP entry configured for the packets destined to a particular interworking interface and the NE2 router (Fig 36) must have a static destination MAC configured on PPP interworking interface Dynamic ARP The purpose of dynamic ARP mode in PPP interworking interface is to learn the destination MAC of the PE router An application with PPP interworking mode is illustrated in Fig 36 The destination MAC address is used to forward the CPE IP traffic to PE router through the Ethernet PWE3 In dynamic mode, router uses ARP to resolve and map the IP address into the next-hop MAC address on an Ethernet interface of PE router PWE3 UP status is a trigger to generate an ARP request on Ethernet PWE3 PPP interworking interfaces In order to enable ARP request generation, e.g from NE2 towards PE, then both PE side IP address (peer router address) and CPE side address (CPE router address) on Ethernet PWE3 PPP interworking interfaces must be configured In normal conditions ARP remains resolved as long as the PWE3 is up Traffic from CPE to PE router will be blocked until NE2 router learns the destination MAC address of PE router PPP Interworking ARP Information Dynamic ARP entries are learned and maintained by the PPP interworking ARP processing based on the PWE3 state: • PWE3 state UP: ARP request will be triggered to the PE router based on the configured PE and CPE side addresses The entries are added into the table as a result of successful ARP resolution and traffic starts flowing in both the directions, i.e from CPE to PE and vice-versa • PWE3 state DOWN: learned ARP entries will be deleted and traffic will be stopped on both directions, i.e from CPE to PE and vice-versa Dynamic ARP entries may be aged out, or updated (by new ARP) Usual dynamic ARP entries are removed when their age timers expire, or if an interface/PWE3 goes down and traffic would be stopped on both directions However, if there has been traffic to a particular destination, ARP refresh is always performed before an ARP entry ages out ARP information is accessible via #ipiw# interface Each #ipiw# instance holds one ARP entry Gratuitous ARP A gratuitous ARP is an announcement broadcast-type of message (request or reply) that can be used for change notification, e.g when there is a CPE side IP address or source MAC address change in PPP interworking interface In this case, a router can use gratuitous ARP to notify other routers so that they can update their ARP entries ARP Rate Limiter To protect against ARP flooding, rate limiters are supported in Ethernet to PPP direction to limit the number of ARP packets received to the host and avoid CPU congestion ARP Faults While processing ARP request or reply messages on PPP interworking interface, a router may raise the following faults (security service or mechanism violation): 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide 175 Layer Descriptions ARP Faults Fault Description arp dynamic request for permanent entry: Dynamic ARP (request from other node or reply without request) tries to modify static ARP entry Possible security attack arp ip address duplicate with me: Dynamic ARP (request from other node or reply without request) uses an IP address configured to this node Possible security attack arp reply interface conflict: Dynamic ARP reply received from unexpected interface Possible security attack arp request incomplete: PPP interworking interface initiated ARP request based on PWE3 status (UP) is incomplete Upgrade from Static to Dynamic To upgrade from static ARP support to dynamic ARP support, the 24xchE1/chT1 MS IFM mode must be changed from DEFAULT mode to IPIW mode (default mode is Frame Relay), clean-up the relevant Frame Relay configuration Static ARP is supported in both default and IPIW modes PWE3 Redundancy The PPP interworking function also supports Ethernet PWE3 redundancy and internal Ethernet PWE3 (internal bridge) in both static and dynamic ARP modes In dynamic ARP mode, the destination MAC (ARP entry) learned via a primary PWE3 will be populated to alias PWE3 When PWE3 switchover from the primary to alias based on the PWE3 fault, traffic will continue to flow on alias PWE3 After a switchover ARP refresh will be triggered to the PE node Limitations and Restrictions The following are the known limitations and restrictions with PPP interworking ARP functionality: • MLPPP interface is not supported • Frame Relay coexistence with PPP interworking is not supported • PPP interworking function with IS-IS protocol is not supported • Mediation of inverse ARP is not supported • IPIW is not supported on 4xchSTM-1/chOC-3 or 1xchSTM-1/chOC-3 MS IFMs IP Header Compression IP Header Compression (IPHC) is technic used to compress excess protocol headers at transmitter (compressor) and restore to their original state at the receiver end of the link (decompressor), thus allowing efficient usage of link bandwidth IPHC is made possible due to the redundancy in the header fields of the same packet as well as consecutive packets of the same packet stream IPHC is defined in [RFC2507] and [RFC3544] In context of IPHC, an IP packet can be of the following types: 8600 Smart Routers FP7.0 Interface Configuration Guide 176 76.8670-50180A © 2015 Coriant Layer Descriptions • Regular IP packet - a normal uncompressed IP packet, that doesn't carry a CID; • Full header packet - an uncompressed header packet carrying IP header and CID, used to update or refresh a context for packet stream; • Compressed header packet - an IP packet (CID and changing fields) with reduced header size or header fields IPHC process uses the concept of flow context, i.e a collection of information about field values and changes patterns of field values in the packet header The context is formed on the compressor and decompressor for each packet flow Once the context is established IPHC operation is performed At certain intervals and in cases of error recovery, full header packets are transmitted to reconstruct the context In IPHC operation, a compressor assigns a Context Identifier (CID) to each packet stream and embeds the CID in the compressed header The CID is used by decompressor for retrieving the context of a compressed packet stream The function of a compressor is to reduce the size of the header fields by means of removing header fields or reducing the size of the header fields The following actions are performed: • Verify incoming packet and classify the packet type; • Identify the packet stream CID; • Check whether the packet header contents are same as that stored in the context; • Compress the headers and transmit the packet A decompressor receives the packet only if it was earlier identified as a full header or compressed header If the packet is a compressed header: • Retrieves the CID from the packet; • Performs lookup on the CID and retrieves the context of the packet stream; • If the context state is as expected, decompressor reconstructs the compressed header with the help of the context Detailed Operation To initiate IPHC for a packet stream, a full header packet has to be first transmitted over the link The compressor and decompressor store most of the fields of the full header packet as context The context consists of the constant fields that need not be transmitted in every packet Any change of the fields that are expected to be constant in a packet stream will cause a compressor to send a full header packet again to update the context at the decompressor As long as the context is the same at both ends of the link, headers will be compressed for a packet stream Due to the fact that packets may be lost during transmission, IPHC requires a mechanism to update the context at the decompressor and also to detect or avoid incorrect decompression Various techniques are used for recovering after packet loss for non-TCP packets: • Compression slow-start • Periodic header refresh 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide 177 Layer Descriptions In compression slow-start, to allow decompressor to quickly recover from loss of a full header that would have changed the context, full headers are sent periodically (F_PERIOD) with an exponentially increasing period after a change in the context F_PERIOD is a parameter defining how many compressed headers may be sent between full headers When the headers of a non-TCP packet stream change and consequently its context too, a full header will be sent and F_PERIOD set to one After sending F_PERIOD compressed headers, a full header is sent F_PERIOD is twice increased each time a full header is sent during compression slow-start In periodic header refresh, to avoid losing too many packets when decompressor has lost its context, an upper limit period (F_MAX_PERIOD) is defined, as the number of consecutive compressed headers that may be sent between header refreshes If a packet is to be sent and F_MAX_PERIOD compressed headers have been sent since the last full header for this packet stream was sent, a full header is sent Also to avoid long periods of disconnection for low data rate packet streams, there is an upper time limit (F_MAX_TIME), which is maximum time between consecutive full headers in a non-TCP packet stream If a packet is to be sent and more than F_MAX_TIME seconds have elapsed since the last full header was sent for this packet stream, a full header is sent A potential target application for IPHC is on low speed links carrying IP traffic with small packet size, e.g VoIP This would include voice over UDP/IP and CESoPSN with UDP/IP PWE3 encapsulation IPHC efficiency is a complex function of different factors The compression performance is affected by the following: • Configuration - e.g the rate of full headers sent; • MLPPP header - adds overhead; • Rate of change of streams - e.g adding new streams at high rate; • Packet sizes - e.g with smaller packets, the higher the IPHC efficiency A set of counters is available from which IPHC efficiency can be derived IPHC Monitoring IPHC cumulative CID counters might be updated differently in both compressor and decompressor because only compressor knows exactly when CID has been allocated, and decompressor concludes the same when the stream related to CID becomes different Therefore, when compressor allocates CID for a packet stream in such a way that the same CID was also earlier allocated for the same packet stream (same UDP/IP header) then decompressor will not update allocated CID counter Thus, allocated CID counter in compressor is accurate while the same in decompressor may have missed some counter updates Configuration Options IPHC functionality is supported in the 4xchSTM-1/chOC-3 MS IFM for IPv4 /UDP over MLPPP encapsulation as specified in [RFC3544] Up to 64K IPHC packet streams are supported per 4xchSTM-1/chOC-3 MS IFM While the number of compressed streams is 64K (65535) on the IFM level, the number of compressed streams supported per interface 16K In order to establish IPHC, peers (compressor and decompressor) must agree on a set of the configuration parameters [RFC2507] and outlined in the following table during negotiation 8600 Smart Routers FP7.0 Interface Configuration Guide 178 76.8670-50180A © 2015 Coriant Layer Descriptions Parameter Description Range REFRESH_PERIOD Maximum number of compressed non-TCP headers that may be sent without sending a full header (known as F_MAX_PERIOD), headers – 65535 REFRESH_TIME Maximum time interval between full headers in seconds (known as F_MAX_TIME) – 255 NON_TCP_SPACE Maximum CID value for non-TCP packet stream – 65535 IPHC is also supported across MSP and APS 1+1 protection Fault Management The supported TDM fault management function is available as described in chapter Fault Management Operation and Configuration 76.8670-50180A © 2015 Coriant 8600 Smart Routers FP7.0 Interface Configuration Guide 179 ... Configuration Guide (76. 86 70- 501 79) • 8 600 Smart Routers FP7. 0 Interface Configuration Guide (76. 86 70- 501 80) (for 86 30 Smart Router and 86 60 Smart Router) 76. 86 70- 501 80A © 201 5 Coriant 8 600 Smart Routers... 8 600 Smart Routers FP7. 0 Interface Configuration Guide 24 76. 86 70- 501 80A © 201 5 Coriant 76. 86 70- 501 80A © 201 5 Coriant Fig IFM Combinations in IFC1 Overview 8 600 Smart Routers FP7. 0 Interface Configuration. .. 76. 86 70- 501 80A © 201 5 Coriant 8 600 Smart Routers FP7. 0 Interface Configuration Guide 19 Overview 8 600 Smart Routers FP7. 0 Interface Configuration Guide 20 Fig IFM Combinations in 86 20 Smart Router