Reprinted with permission of NCTA, from the 2014 Cable Connection Spring Technical Forum Conference Proceedings. For more information on Cisco solutions, visit: http://www.cisco.com/c/en/us/solutions/index.html
For some very basic VRF configuration follow the steps:
1. Enters VRF configuration mode and assigns a VRF name.
Router(config)#ip vrf vrf-name
2. Creates a VPN route distinguisher (RD) following one of the 16bit-ASN:32bit-number or 32bitIP:16bit-number explained above
Router(config-vrf)#rd route-distinguisher
3. Creates a list of import and/or export route target communities for the specified VRF.
Router(config-vrf)# route-target {import | export | both} route-distinguisher
4. (Optional step) Associates the specified route map with the VRF.
Router(config-vrf)# import map route-map
Marek Isalski, Faelix.net Ltd, describes the MikroTik range of routers and their applications, gives a pros and cons summary, and recommendations for budget provider edge deployment.
For some very basic VRF configuration follow the steps:
1. Enters VRF configuration mode and assigns a VRF name.
Router(config)#ip vrf vrf-name
2. Creates a VPN route distinguisher (RD) following one of the 16bit-ASN:32bit-number or 32bitIP:16bit-number explained above
Router(config-vrf)#rd route-distinguisher
3. Creates a list of import and/or export route target communities for the specified VRF.
Router(config-vrf)# route-target {import | export | both} route-distinguisher
4. (Optional step) Associates the specified route map with the VRF.
Router(config-vrf)# import map route-map
Marek Isalski, Faelix.net Ltd, describes the MikroTik range of routers and their applications, gives a pros and cons summary, and recommendations for budget provider edge deployment.
Fiber optics in-buildings infrastructure paper - OEA- LebanonKSU
This review paper discusses the benefits of fibre broadband and considerations for real estate developers in Lebanon; it compares different FTTx network architectures, the standardization of building network elements, the need for local legislations and describes typical FTTH deployments worldwide.
Wireless-fiber convergence: Ethernet at Fronthaul creating new possibilities ...Dhiman Chowdhury
Front-haul Mobile Networks is undergoing rapid changes that separates RF block from baseband unit making it possible for long distance deployment of baseband units. This is just the prelude for more robust transformation to occur. Once such possibility is transforming fronthaul with Ethernet paving the way for higher bandwidth and easier adoption of 5G.
This article discusses changes in RRH to BBU connectivity technology known as D-ROF and discusses ruse of Ethernet in D-ROF and possibility of using whitebox for front-haul mobile networks.
A NEW SYSTEM ON CHIP RECONFIGURABLE GATEWAY ARCHITECTURE FOR VOICE OVER INTER...csandit
The aim of this paper is to present a new System on Chip (SoC) reconfigurable gateway
architecture for Voice over Internet Telephony (VOIP). Our motivation behind this work is
justified by the following arguments: most of VOIP solutions proposed in the market are based
on the use of a general purpose processor and a DSP circuit. In these solutions, the use of the
serial multiply accumulate circuit is very limiting for the signal processing. Also, in embedded
VOIP based DSP applications, the DSP works without MMU (memory management unit). This
is a serious limitation because VOIP solutions are multi-task based. In order to overcome these
problems, we propose a new VOIP gateway architecture built around the OpenRisc-1200-V3
processor. This last one integrates a DSP circuit as well as a MMU. The hardware architecture
is mapped into the VIRTEX-5 FPGA device. We propose a design methodology based on the
design for reuse and design with reuse concepts. We demonstrate that the proposed SoC
architecture is reconfigurable, scalable and the final RTL code can be reused for any FPGA or
ASIC technology. Performances measures, in the VIRTEX-5 FPGA device family, show that the
SOC-gateway architecture occupies 52% of the FPGA in term of slice LUT, 42% of IOBs, 60%
of bloc memory, 8% of integrated DSP, 16% of PLL and the total power is estimated at
4.3Watts.
A NEW SYSTEM ON CHIP RECONFIGURABLE GATEWAY ARCHITECTURE FOR VOICE OVER INTER...cscpconf
The aim of this paper is to present a new System on Chip (SoC) reconfigurable gateway architecture for Voice over Internet Telephony (VOIP). Our motivation behind this work is
justified by the following arguments: most of VOIP solutions proposed in the market are based on the use of a general purpose processor and a DSP circuit. In these solutions, the use of the serial multiply accumulate circuit is very limiting for the signal processing. Also, in embedded VOIP based DSP applications, the DSP works without MMU (memory management unit). This is a serious limitation because VOIP solutions are multi-task based. In order to overcome these
problems, we propose a new VOIP gateway architecture built around the OpenRisc-1200-V3 processor. This last one integrates a DSP circuit as well as a MMU. The hardware architecture is mapped into the VIRTEX-5 FPGA device. We propose a design methodology based on the design for reuse and design with reuse concepts. We demonstrate that the proposed SoC architecture is reconfigurable, scalable and the final RTL code can be reused for any FPGA or ASIC technology. Performances measures, in the VIRTEX-5 FPGA device family, show that the SOC-gateway architecture occupies 52% of the FPGA in term of slice LUT, 42% of IOBs, 60% of bloc memory, 8% of integrated DSP, 16% of PLL and the total power is estimated at 4.3Watts
Since the photonic layer is the cheapest on a per-bit, per-function basis, and since
the key imperative before operator's today is to bridge the yawning gap between
exponentially increasing data traffic on the one-hand, and flat-to-declining revenues
on the other, a tighter coupling between the packet and optical layers to derive
operational, management, and deployment efficiencies, has...
Cisco will be at OFC, the world’s premier optical event again showcasing our industry leading Packet Optical Convergence innovations and solutions. We encourage you to be part of the experience by visiting our Exposition booth (#3109) where you can interact with Cisco demonstrations, technical experts and Cisco Service Provider executives.
[Infographic] Cisco Visual Networking Index (VNI): Mobile-Connected Devices p...Cisco Service Provider
This Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast infographic provides some of the global and regional highlights from the updated study that covers forecast for 2014 to 2019.
For more information, please tweet us @CiscoVNI and follow our hashtag #VNI, and visit: http://cs.co/vnilpss.
[Infographic] Cisco Visual Networking Index (VNI): Mobile Users GrowthCisco Service Provider
This Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast infographic provides some of the global and regional highlights from the updated study that covers forecast for 2014 to 2019.
For more information, please tweet us @CiscoVNI and follow our hashtag #VNI, and visit: http://cs.co/vnilpss.
Operating costs decrease and agility increases, allowing you to react quickly to new market opportunities.
http://www.cisco.com/web/offers/sp04/simplifying-operations/index.html?KeyCode=000947566
Service creation is simpler and delivery is faster, allowing you to react quickly to new market opportunities.
http://www.cisco.com/web/offers/sp04/entering-new-markets/index.html?KeyCode=000947734
What if the orchestrator could also automate the deployment and configuration of an accompanying service assurance solution, tailored to the specific services being delivered? This is now becoming a reality using a concept called Orchestrated Assurance.
Operator Drives Bandwidth Efficiency and Optimizes Satellite Link PerformanceCisco Service Provider
Providing network connectivity and services, such as data, voice, live TV, high- definition (HD) on-demand video, and mobile services, EMC caters to customers with operations in some of the most remote corners of the planet. Managing satellite bandwidth requires sophisticated monitoring tools to ensure consistent performance of voice, video and data during events, such as rain, that can affect the quality. This telecommunications leader prides itself on delivering carrier-class services through its global mobility platform, using its hybrid satellite and terrestrial broadband network.
The EMC network features fully meshed, Multiprotocol Label Switching (MPLS) enabled and interconnected teleports in the United States, Europe, South America, Africa, and Asia. With EMC’s proprietary tools, it can manage and optimize every megabyte delivered. Its customer-facing tools further maximize every bit delivered over each customer’s WAN and LAN.
Application Engineered Routing Segment Routing and the Cisco WAN Automation ...Cisco Service Provider
The Cisco® Application Engineered Routing solution provides end-to-end control over how the network infrastructure transports applications. In the past, dedicated clusters of servers would deliver specific applications, but the number and diversity of applications continue to increase as the infrastructure becomes more converged.
Traffic patterns are dynamically changing and new applications come with specific transport requirements. Combining Segment Routing (SR) with the Cisco WAN Automation Engine (WAE) provides the necessary intelligence to optimize network resources and make informed decisions dynamically, helping to ensure a consistent, high-quality customer experience.
This white paper describes SR and the Cisco WAE and highlights how they work together to deliver an intelligent, dynamic, highly optimized network.
Research Highlight: Independent Validation of Cisco Service Provider Virtuali...Cisco Service Provider
Service providers want to know how they can build and run programmable, intelligent, responsive, efficient, flexible, and highly secure yet open networks with a high degree of automation. They want to be able to configure and activate new services quickly, utilize emerging cloud capabilities, and meet customer needs. Nimble, smart innovators in the global communications and networking industry are working on the answers and coming up with solutions every day. But providers need to know if these next-generation technologies can already meet their requirements today
In the world of service providers and networks, the demand for new and better services continue to grow, while the networks must expand and quickly adapt to these demands. One way that operators are evolving their network is to adopt some of the latest technologies like NFV (network functions virtualization). Infonetics recently found that 35 percent of the worldwide telecom carriers they surveyed are planning to deploy NFV in 2015. They are doing this because they believe that NFV and its SDN (software-defined networking) architecture will deliver benefits in service agility and new revenue, operational efficiencies and capex savings. Finding new ways to build revenue paths out of the network is critical for operators today as they innovate to find new sources of revenues.
Operators have been looking to Policy to help them find new ways to find value in their network. Specifically, they need a policy platform which can help them quickly adapt to build new services and even new networks for other operators or enterprises. We are now announcing the availability of Cisco Policy Suite version 7.5 for download. With it, operators will benefit from NFV-based policy enforcement and new access selection technologies. These new capabilities are enabling service providers to not only use policy software to open new services and markets, but they are also providing policy to the handset to ensure the best access method for the end user.
Deploy New Technologies Quickly with Cisco Managed Services for Service Provi...Cisco Service Provider
Service providers’ businesses and operations are undergoing major changes. New initiatives, like IP convergence, cloud, software-defined networks and network virtualization, are driving new business models. These initiatives are also creating opportunities for new revenue streams and greater efficiencies. Speed, agility and flexibility are required for fast access to IT and new applications. Now is the time to invest effort and resources in figuring out how to make this opportunity work for you. You have a chance to disrupt rather than being disrupted.
Segment routing is a network technology focused on addressing the pain points of existing IP and Multiprotocol Label Switching (MPLS) networks in terms of simplicity, scale, and ease of operation. It’s a foundation for application engineered routing because it prepares the networks for new business models where applications can direct network behavior.
Segment routing seeks the right balance between distributed intelligence and centralized optimization and programming. It was built for the software-defined networking (SDN) era.
Segment routing enables enhanced packet forwarding behavior. It enables a network to transport unicast packets through a specific forwarding path, other than the normal shortest path that a packet usually takes. This capability benefits many use cases, and you can build those specific paths based on application requirements.
Segment routing uses the source routing paradigm. A node, usually a router but it can also be a switch, a trusted server, or a virtual forwarder running on a hypervisor, steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to a segment-routing node or global within a segment-routing network. Segment routing allows you to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the segment-routing network. To be aligned with modern IP networks, segment routing supports equal-cost multipath (ECMP) by design, and the forwarding within a segment-routing network uses all possible paths, when desired.
Cisco Virtual Managed Services: Transform Your Business with Cloud-based Inn...Cisco Service Provider
Service providers face big challenges along with tremendous opportunities. Maturing technologies such as software-defined networking (SDN), network function virtualization (NFV), cloud, and open-source software are enabling exciting business innovations and market disruptions. To keep up with the pace of change today, you need to rethink how to engage with your customers to meet their business needs. At Cisco, we have the right approach to harness the transformative power of the cloud, SDN, and NFV. The Cisco® Virtual Managed Services Solution portfolio provides a rich set of secure cloud-based network services with prepackaged software capabilities over any access technology. The Cisco Virtual Managed Services solution makes it easy for you to deploy, manage, and sell new premium cloud managed services while reducing current operating expenditures (OpEx) and accelerating time to revenue.
Imagine if you could deploy highly secure new services at web speed on demand to customers and partners - complete with personalized capabilities. With this environment you’re creating innovative new services in minutes, not months, accelerating your time-to-revenue while reducing operational costs on an open platform. You have pre-packaged software service solutions that help you transform your business and the businesses of your customers. And you’re letting your customers use their existing customer premises equipment (CPE), to connect to virtual services from the cloud, reducing capital costs and business risk associated with rolling out new services.
It’s all possible with the Cisco Virtual Managed Services Solution based on the combination of the complementary Cisco Evolved Programmable Network (EPN) and the Cisco Evolved Services Platform (ESP). This open infrastructure and software combined with industry leading service orchestration, software-defined networking (SDN), and network functions virtualization (NFV) technologies automate the delivery of business services tailored to your customers from the cloud.
Cisco cBR-8 Evolved CCAP: Deliver Scalable Network and Service Growth at a Lo...Cisco Service Provider
An explosion of new over-the-top (OTT) video services and consumer devices is placing huge demand on cable access networks. To compete for new customers and retain the loyalty of existing ones, multiple system operators (MSOs) will need to expand capacity substantially, rolling out new services and gigabit tiers.
As they strive to meet insatiable market demand and stay competitive, MSOs are looking at significant access network capital expenditures (CapEx) increases over the next 5 years - and steadily rising operating expenses (OpEx) due to higher power costs and a larger network footprint. But current integrated Cisco® Converged Cable Access Platform (CCAP) solutions are limited to supporting only 24 to 32 channels per service group, and they are not designed to support DOCSIS® 3.1 at scale. Using these platforms, MSOs would need to significantly increase CapEx spend in order to compete with gigabit billboard rates and keep pace with growth.
Alternatively, MSOs can use the Cisco cBR-8 Converged Broadband Router, a full-spectrum CCAP-compliant platform that is designed to support DOCSIS 3.1. The Cisco cBR-8 enables cable operators to offer multigigabit broadband and Internet of Everything (IoE) services, and provide a path to virtualization. It empowers MSOs to scale economically to deliver more capacity and best-in-class services with much lower total cost of ownership (TCO).
This white paper examines the consumer trends affecting cable access networks and the projections for how the network and services will evolve in the coming years. It provides a long-term economic analysis of an evolved access network using the Cisco cBR-8, compared with competitive Advanced Telecommunications Computing Architecture (ATCA) platforms. And it demonstrates how MSOs will be able to meet capacity and service demands over the next several years at a 40-percent savings in hardware, space, and power costs.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Welcome to the first live UiPath Community Day Dubai! Join us for this unique occasion to meet our local and global UiPath Community and leaders. You will get a full view of the MEA region's automation landscape and the AI Powered automation technology capabilities of UiPath. Also, hosted by our local partners Marc Ellis, you will enjoy a half-day packed with industry insights and automation peers networking.
📕 Curious on our agenda? Wait no more!
10:00 Welcome note - UiPath Community in Dubai
Lovely Sinha, UiPath Community Chapter Leader, UiPath MVPx3, Hyper-automation Consultant, First Abu Dhabi Bank
10:20 A UiPath cross-region MEA overview
Ashraf El Zarka, VP and Managing Director MEA, UiPath
10:35: Customer Success Journey
Deepthi Deepak, Head of Intelligent Automation CoE, First Abu Dhabi Bank
11:15 The UiPath approach to GenAI with our three principles: improve accuracy, supercharge productivity, and automate more
Boris Krumrey, Global VP, Automation Innovation, UiPath
12:15 To discover how Marc Ellis leverages tech-driven solutions in recruitment and managed services.
Brendan Lingam, Director of Sales and Business Development, Marc Ellis
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
The Metaverse and AI: how can decision-makers harness the Metaverse for their...Jen Stirrup
The Metaverse is popularized in science fiction, and now it is becoming closer to being a part of our daily lives through the use of social media and shopping companies. How can businesses survive in a world where Artificial Intelligence is becoming the present as well as the future of technology, and how does the Metaverse fit into business strategy when futurist ideas are developing into reality at accelerated rates? How do we do this when our data isn't up to scratch? How can we move towards success with our data so we are set up for the Metaverse when it arrives?
How can you help your company evolve, adapt, and succeed using Artificial Intelligence and the Metaverse to stay ahead of the competition? What are the potential issues, complications, and benefits that these technologies could bring to us and our organizations? In this session, Jen Stirrup will explain how to start thinking about these technologies as an organisation.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdf
Remote PHY for Converged DOCSIS, Video and OOB
1. Remote PHY for Converged
DOCSIS, Video and OOB
John T. Chapman, CTO Cable Access BU & Cisco Fellow
jchapman@cisco.com
Cisco
Abstract
Remote PHY refers to the technique of
moving the PHY circuit out of a device such
as a CCAP and putting the PHY circuit at the
end of a network. Remote PHY builds upon
the work started with Modular CMTS (M-
CMTS) and Modular Headend Architecture
(MHA) at CableLabs.
Remote PHY is an evolving set of
specifications and products. This white paper
will focus on the expanded definition and the
updates to the transport and timing for
Remote PHY and how they apply to DOCSIS,
MPEG-TS video, and Out-of-Band signaling
for STB.
TABLE OF CONTENTS
TABLE OF CONTENTS.........................................1
INTRODUCTION ...................................................2
DISCLOSURE.................................................................2
WHAT IS REMOTE PHY?...........................................2
REMOTE PHY LINEAGE.............................................2
WHY IS DIGITAL HFC INTERESTING?.....................3
REVIEW OF COMPARABLE TECHNOLOGIES ............4
BDR/BDF..................................................................4
Remote PHY.............................................................4
Remote MAC............................................................5
Remote CMTS .........................................................5
CURRENT MHA TECHNOLOGY ........................5
OVERVIEW ...................................................................5
DEPI.............................................................................5
D-MPT Pseudowire..............................................6
PSP Pseudowire.....................................................7
REMOTE PHY TECHNOLOGY............................8
OVERVIEW ...................................................................8
SPECIFICATIONS AND APPLICATIONS......................8
Remote PHY Pseudowire...................................8
UEPI............................................................................9
R-DTI..........................................................................9
R-OOB ........................................................................9
NEW PROTOCOL EXTENSIONS ....................... 9
PACKET LENGTH.........................................................9
MPLS............................................................................9
MCM: MULTI-CHANNEL MPT.............................. 10
BFD ........................................................................... 10
DOCSIS 3.1.............................................................. 11
DS OFDM Channel Pseudowire ....................11
DS PLC Channel Pseudowire.........................11
D3.1 Upstream Pseudowires.........................11
VIDEO......................................................................... 12
OOB........................................................................... 12
REMOTE PHY TIMING......................................13
R-DTI – ONE-WAY REVERSE ............................... 13
R-DTI – TWO-WAY REVERSE .............................. 14
R-DTI – TWO-WAY FORWARD ............................ 14
REMOTE SCHEDULER.............................................. 14
DETAILS..................................................................... 15
Packet Formats...................................................15
Support for DTP..................................................15
Distances................................................................15
NEXT STEPS.........................................................15
SUMMARY............................................................16
REFERENCES.......................................................16
Related Papers by the Same Author..........16
Related CableLabs Specifications...............17
Related IETF Specifications...........................17
2. INTRODUCTION
Disclosure
The ideas described in this paper are
being considered to become part of a formal
set of public Remote PHY specifications.
The Remote PHY specifications are still
under development. The following represents
the author’s current thoughts on the
requirements, form, and functionality of the
Remote PHY protocol. Since actual bit
positions within the protocol are still being
finalized, they are not explicitly specified in
this white paper.
However, this white paper should be a
fairly accurate guide to what the Remote
PHY protocol can accomplish and how it
operates.
What is Remote PHY?
Figure 1 - Remote PHY CCAP Network
Remote PHY is an architectural strategy
that removes the PHY element from a
product and places that PHY element in a
separate access point that is interconnected
with an IP network (even simple Metro
Ethernet networks or just EPONs qualify as
they use IP packets). This is shown in Figure
1 and explained in the white paper [8].
Restated, Remote PHY allows you to put
your main chassis at one end of a network
and your PHY chip at the other end of the
network. This is a useful technique when the
PHY chip needs to be close to an access
network, but the desire is to put the
intelligence and complexity in a central
location that has more room and is more
serviceable.
Remote PHY infers centralized software.
The least amount of complexity is placed
remotely; the most amount of complexity is
retained centrally.
Remote PHY-like strategies (similar in
concept but different in implementation)
have been used in adjacent markets such as:
WiFi access points
LTE access points
Ethernet over Coax (EoC)
EPON over Coax (EPoC)
xDSL
Remote PHY in this context was applied
initially to a DOCSIS CMTS. Remote PHY
is also now being applied to traditional
MPEG-TS video and to out-of-band (OOB
signaling).
Remote PHY Lineage
The first instance of Remote PHY
technology was the Modular CMTS (M-
CMTS) specifications from CableLabs in
2005. Architecture and tutorial discussions of
M-CMTS can be found in white papers [11],
[12] and [13].
The specifications included:
DEPI – DOCSIS External PHY
Interface
DTI – DOCSIS Timing Interface
CCAP
Core
(MAC)
Service
Flow
Engine
CCAP
Access
Point
(PHY)
DOCSIS
CM
Digital Fiber
DOCSIS
Provisioning System
DOCSIS
Policy Server
DOCSIS
PacketCable
DOCSIS Signaling
Internet
MHAv2 Signaling
Coax
3. ERMI – Edge Resource Management
Interface
M-OSSI – M-CMTS Operations
Support System Interface Specification
These specifications where targeted at
combining CMTS and Edge QAMs (EQAM)
together into one system. While the original
intent was to lower the system cost, the real
benefit ended up being the ability to greater
customize the CMTS for cost and
performance.
At the time, another specification was
written but was not published, as there was
no market application for it. That spec was:
UEPI – Upstream External PHY
Interface
UEPI builds upon the DEPI pseudowire
concepts and applied them to the upstream
CMTS MAC-PHY interface. In 2006, UEPI
was used as a MAC to PHY interface for
vendor silicon for I-CMTS applications.
In 2008, a second round of specifications
that focused on the EQAM were published.
Since the set of specifications now referred to
more than just the CMTS, they were renamed
as the Modular Headend Architecture (MHA)
specifications. These specifications were:
EQAM-PMI – Edge QAM
Provisioning and Management
Interface
EQAM-VSI – Edge QAM Video
Stream Interface
MHA Technical Report
In 2012, the Chinese national regulatory
body for the cable industry known as SARFT
(State Administration of Radio, Film, and
Television) adopted DEPI and UEPI as C-
DOCSIS (China DOCSIS) Type III.
Also in 2012, the Remote PHY
technology won a China CRTA Scientific
and Technological Innovation Award, shown
in Figure 2.
Figure 2 - Remote PHY Innovation Award
It is anticipated that the work described
in this white paper will evolve into industry
specifications as well.
Why is Digital HFC Interesting?
One of the product goals of Remote
PHY is to put Remote PHY technology into
an Optical Node in an HFC (Hybrid Fiber
Coax) Plant. This would allow the fiber
portion of the HFC plant to become digital.
To date, the HFC forward path has used
analog optics and the reverse path has used
both analog and digital optics.
The conversion of the HFC plant from a
linear optics plant to a digital optics plant
would be applicable anytime the plant is to
be segmented or upgraded. The most
compelling case is deep fiber. Today’s plant
is typically N+5, which refers to an optical
node plus 5 amplifiers deep. A deep fiber
4. plant design would be N+0 or N+1, meaning
an optical node plus no or one amplifier.
In a deep fiber plant, there are many
more optical nodes, head end optical lasers
and receivers, as well as CMTS ports to be
purchased. A conversion to digital fiber may
yield a better investment decision.
Digital forward and reverse paths are
interesting for technical and strategic
reasons. The technical reasons are:
Longer distances (80+ km vs. 40 km)
More wavelengths (80 vs. 16)
Lower cost optics (based upon 10G
Ethernet)
Higher throughput (more bits per
Hertz) if the DOCSIS 3.1 PHY is
located after the coax segment.
Lower maintenance costs
Higher Reliability
If the digital fiber is also an IP network
(or Metro Ethernet or EPON/GPON
network), then there are also additional
strategic benefits:
Compatibility with digital access
networks which are now appearing
internationally
Good scaling for deep fiber
The same IP-based access network can
be used for residential and commercial
use.
The same IP-based access network can
be used to support DOCSIS (with
Remote PHY) and fiber to the home
(FTTH).
Review of Comparable Technologies
Table 1 - Technology Comparison
Criteria
BDR,
BDF
Remote
PHY
Remote
MAC
Remote
CMTS
IP
Network
No Yes Yes Yes
I-CMTS
impact
Low Low High Low
Remote
SW
0% 5% 50% 100%
Remote
HW
5% 10% 40% 100%
There are several ways to address the
market need for digital HFC. These methods
are shown in Table 1 and they are ranked to
several basic criteria that define them. [9]
BDR/BDF
The most basic approach would be to do
a baseband digital forward (BDF) in a similar
manner to how baseband digital reverse
(BDR) was done. This has been too costly to
date to do, but may become feasible in the
future. The main advantage of this approach
is that it is transparent to any modulation or
service that goes across it. The main
disadvantage is that it maintains a single hop
proprietary fiber interface. Even if BDF
where to adopt a network packet format, the
network traffic would be very high
bandwidth and continuously on 100% of the
time. It also does not allow the CMTS to
Remote PHY path to traverse a generic IP
network.
There are three variations on the
DOCSIS CMTS theme, all of which support
IP networking.
Remote PHY
Remote PHY, the subject of this white
paper, puts the bare minimum hardware and
software into a remote entity. Remote PHY
5. keeps all the complexity centralized where it
can be more easily scaled and maintained.
The advantage of Remote PHY is its
simplicity. The disadvantage is that the PHY
definition has to be committed to and not
changed. (Note that an overlay network could
deal with changes, but the long term goal is
that an overaly network should not be
required).
Remote MAC
Remote MAC puts the DOCSIS PHY,
the MAC, and a good amount of packet
processing and software into the remote
entity. Some examples are C-DOCSIS Type
II and the PASI interface that was under
development in CCAP but was later
cancelled.
The advantage of the Remote MAC
approach is that the CMTS-Core could be
replaced with alternative products such as
generic BRAS (Broadband Remote Access
Server). The disadvantages of this approach
are that there is no compatibility with an I-
CMTS and the remote phy entity is more
complex.
Further, to prevent truck rolls and
upgrades, the remote node has to implement
full spectrum DOCSIS MAC processing
years before full spectrum DOCSIS is
needed. It also requires the millions of lines
of DOCSIS specific CMTS code to be
decomposed and ported to the BRAS and
MAC PHY node. This is a huge code
stability concern, and an unnecessary risk.
Remote CMTS
Remote CMTS puts the entire CMTS
into the node. The advantage of this approach
is that the software model for the CMTS is
not split in half, as is the case with Remote
MAC. The disadvantages of Remote CMTS
are that there are now 1000’s of CMTS to
configure and the node is not a secure
location that was always an assumption for
BPI (Baseline Privacy).
Of these choices, this white paper would
like to suggest that Remote PHY provides
the optimum balance of supporting IP
networking and still striving for maximum
simplicity and compatibility with existing
CCAP devices.
CURRENT MHA TECHNOLOGY
Overview
Figure 3 - MHA System Diagram
In a current MHA system, the
downstream DOCSIS PHY is located
externally in an EQAM while the upstream
DOCSIS PHY remains in the CMTS-Core.
The interface for the downstream PHY is
DEPI.
DEPI
Figure 4 - DEPI Pseudowire Format
DEPI is the Downstream External PHY
Interface. In an Integrated CMTS (I-CMTS)
6. system, it can be the interface between the
MAC chip and the PHY chip. In a Remote
PHY system, it is the protocol interface
between the MAC interface in the CCAP-
Core and the PHY chip in the Remote PHY
entity.
The general pseudowire format for DEPI
along with a byte count is shown in Figure 4.
The sub-elements of the DEPI packet are as
follows:
Ethernet header
IPv4 or IPv6 header
L2TPv3 header
DEPI header
DEPI Payload
CRC
The first three headers are well defined
by IEEE and IETF specifications. The
published version of DEPI does include an
optional UDP header ahead of the L2TPv3
header. This option was not used in practice
and will be eliminated from the specification.
This also simplifies the L2TPv3 header.
The L2TPv3 header contains a single 32-bit
session ID. If the session ID is all zeros, the
packet is a control plane packet. If the
session ID is non-zero, then it is a data
packet. The control plane will associate a
session ID with a pseudowire type and sub-
type. The base L2TPv3 protocol is in [20].
The format of the DEPI header is
specific to DEPI. The DEPI header also
specifies the format of the DEPI payload.
There are two DEPI pseudowire types.
D-MPT which is the DOCSIS MPEG
Transport pseudowire
PSP which is the Packet Streaming
Protocol pseudowire
Each pseudowire can have a sub-type.
Examples of sub-type are “DOCSIS 3.0
Downstream” and “DOCSIS 3.1
Downstream”. The significance is that the
pseudowire type is part of the normal
L2TPv3 control plane while the pseudowire
sub-type is advertised in the DEPI specific
extensions.
D-MPT Pseudowire
Figure 5 - D-MPT Pseudowire Type
The DOCSIS MPEG-TS pseudowire is
the only pseudowire that was deployed in
DOCSIS 3.0 based M-CMTS systems. As the
name implies, there is a DEPI header
followed by a number of 188 byte MPEG-TS
packets. For M-CMTS, the DEPI packet size
limited the number of MPEG-TS packets to
seven.
The D-MPT header is 32 bits in size and
contains the basic DEPI header that is used in
all the pseudowire types. It contains:
A V bit to permit L2TPv3 payload
multiplexing within an L2TPv3
session.
A S bit to indicate if the sequence field
is valid
Two H bits that allow DEPI payload
multiplexing within a DEPI session.
This is used for DLM, the DEPI
Latency Measurement packet.
7. Three-bit flow ID. Used for indicating
the QoS of the payload.
Segment count for PSP.
Sequence number for the pseudowire
session.
The V bit, S bit, and the sequence
number are recommended fields from
L2TPv3. All the other fields are DEPI
specific.
PSP Pseudowire
Figure 6 - PSP Pseudowire Type
The PSP Pseudowire has a payload that
is divided into one or more segments.
Packets are mapped to segments. A segment
can contain the beginning, middle, or end of
a packet. Payload packets can be split across
multiple DEPI packets. Unlike CCF
(Continuous Concatenation and
Fragmentation) from DOCSIS 3.0, a segment
cannot contain the end of one packet and the
beginning of the next.
The basic PSP pseudowire sub-type only
places packets in the segments. In other sub-
types, segments can be used to carry pre-
pended or post-pended information that is per
packet.
The PSP pseudowire header uses the
same 32-bit header from D-MPT, plus it adds
a segment table. There is one entry in the
segment table for each segment present in the
payload. The entries contain:
Begin bit
End bit
Segment length
The “begin” and “end” bits are used for
packet reassembly. The segment length is
used to find the next segment start byte.
8. REMOTE PHY TECHNOLOGY
This white paper will focus on the
Remote PHY transport. In later white papers,
the control protocols and management/OSS
protocols will be covered in more detail.
Remote PHY technology builds upon the
original DEPI specification.
Overview
Figure 7 - Remote PHY CCAP System
A CCAP (Converged Cable Access
Platform) is a combination of a DOCSIS
(Data Over Cable Service Interface
Specification) CMTS (Cable Modem
Termination System) and an EQAM (Edge
QAM).
An I-CCAP (Integrated CCAP) has the
CMTS and EQAM in one chassis. In a
Remote PHY system, the PHY circuitry from
the I-CMTS is removed and put into the
Remote PHY Entity (this will get a proper
CCAP name later). The remaining parts of
the CCAP are called the CCAP Core. This is
shown in Figure 7.
Note that hybrid approaches are equally
valid. A CCAP system could have both
integrated MAC-PHY line cards and MAC-
only line card that support Remote PHY.
The Remote PHY protocols use the
concept of a pseudowire (PW). A pseudowire
is just a cooler and updated name for an IP
tunnel between two points in an IP network.
Pseudowires can take a specific packet from
one point on an IP network and move it to
another point. In the case of Remote PHY,
pseudowires are used to move MPEG-TS
packets and DOCSIS frames between the
MAC and the PHY.
One of the significant properties of the
Remote PHY Protocols is that it is an IP
packet that can traverse any kind of network.
It can traverse a layer 2 forwarding network,
a layer 3 routed network, an MPLS network,
or even a lambda over fiber network.
Specifications and Applications
Table 2 - Applications and Transports
Transport
Application
DOCSIS Video OOB
DEPI
UEPI
R-DTI
Table 2 shows the basic transports and
timing used in Remote PHY and how three
different applications or higher layer
protocols are mapped to these transports.
Each of the transports and applications will
be described next.
Remote PHY Pseudowire
The generic Remote PHY Pseudowire is
the same as the MHA DEPI pseudowire with
the exception that there are many more sub-
types. In MHA DEPI, there was just the D-
9. MPT and PSP pseudowire types. There are
now a collection of sub-types that add
extensions to D-MPT and PSP.
UEPI
Figure 8 - UEPI Pseudowire
UEPI is the Upstream External PHY
Interface. UEPI is new for Remote PHY and
was not part of the original M-CMTS and
MHA specifications.
UEPI is an extension to L2TPv3. UEPI
uses the PSP pseudowire type from DEPI
and uses the same control plane as DEPI.
UEPI has unique pseudowire types for the
upstream direction that are explained in a
later section. UEPI for DOCSIS 3.0 is
described in [1].
R-DTI
R-DTI is the Remote DOCSIS Timing
Interface. The local version, just known as
DTI, is part of the M-CMTS specifications.
The original DTI protocol defines how a
timing server can run timing to a CMTS-
Core and an EQAM and how both devices
can have the same timestamp. The DTI
protocol is described in [10].
R-OOB
R-OOB is Remote Out-of-Band. OOB is
the signaling channel in the downstream and
upstream that is used to control Set-Top
Boxes (STB).
R-OOB use DEPI and UEPI so that the
pseudowires can be setup and torn down with
the same control plane protocols as rest of
the Remote PHY Pseudowires. R-OOB is
carried as a separate specification since it is a
distinct and potentially separate application.
NEW PROTOCOL EXTENSIONS
Packet Length
DEPI was originally defined with a 1500
byte Ethernet packet. In D-MPT mode, this
allows for up to 7 MPEG-TS packets per
DEPI packet. In the new Remote PHY
specifications, that length will be increased to
approximately 2000 bytes. This will allow up
to 10 MPEG-TS packets per DEPI packet.
MPLS
Figure 9 - DEPI over MPLS
MPLS is Multiple Protocol Label
Switching, and is a method of moving
packets across a network using labels which
can be popped on and off at each network
forward point. MPLS routes are setup using
LDP, the Label Distribution Protocol. MPLS
routes are calculated using protocols such as
MPLS-TE that is MPLS Traffic Engineering.
Technically, there are two underlying
types of pseudowires used in network –
MPLS and L2TPv3. The MPLS pseudowire
is used for native MPLS networks and the
L2TPv3 pseudowire is used for native IP
networks. Each protocol has its own control
plane. If DEPI had been originally designed
10. as an MPLS pseudowire, it would have
added protocol extensions to MPLS-TE.
Since DEPI is just an IP packet, it can be
sent over any network, including an MPLS
network. Since the DEPI control plane is
already well defined and working, the current
direction is to not rebuild DEPI with MPLS-
TE. Instead, the DEPI forwarding plane and
control plane will remain as L2TPv3 and will
(optionally) run on top of MPLS. This is
shown in Figure 9.
Thus, DEPI does not use an MPLS
pseudowire. DEPI uses an L2TPv3 based
pseudowire which can be run over an MPLS
network.
MCM: Multi-Channel MPT
Figure 10 - DEPI MPT/MCM Pseudowire
In the current usage of the MPT
pseudowire, there is one pseudowire for each
QAM channel in the Remote PHY. The
advantage of MPT is that it provides a simple
point-to-point connection from a MAC
channel to a PHY channel. The disadvantage
is that additional latency is incurred in
building up MPEG-TS packets into a DEPI
packet. The latency of ten MPEG-TS
packets at 1 Gbps is 1.6 usec.
While this is not much of an additional
delay, MCM also offers an improvement by
allowing multiple QAM channels to share the
same pseudowire. This also helps with
scaling. For example, instead of having 160
pseudowires for 160 QAM channels,
technically, there could be one really busy
DEPI pseudowire. Typically, there would be
a smaller number of DEPI pseudowires with
a number of pseudowires.
MCM is a sub-type of the main MPT
pseudowire. MCM uses a table in the DEPI
header that lists which MPEG-TS packet in
the DEPI payload goes to which QAM
Channel. A table format in the header is used
rather then tagging each MPEG-TS packet so
that in implementation, the table can be read
and then executed against the rest of the
packet. This is shown in Figure 10.
Note that while any number of QAM
channels can be supported within a
pseudowire, each DEPI packet can only
contain up to 10 MPEG-TS packets in one
packet at one time.
BFD
Figure 11 – DEPI or UEPI with BFD
BFD refers to Bi-Directional Forwarding
Detection. BFD is essentially a loopback
packet that can be used for testing data path
integrity. By integrating BFD directly into
the packet, the entire transmission path from
the DOCSIS MAC channel to Remote PHY
QAM channel can be tested.
Note that BFD can also be sent in a
stand-alone UDP packet. BFD is an industry
standard extension to L2TPv3 and applies to
all DEPI and UEPI pseudowires types and
sub-types. BFD is described in [17], [18] and
[19].
11. DOCSIS 3.1
DOCSIS 3.1 is a new version of
DOCSIS that has recently been released from
CableLabs. DOCSIS 3.1 uses a new physical
layer based upon OFDM (Orthogonal
Frequency Division Multiplexing) and an
error correction scheme called LDPC (Low
Density Parity Check). The data path consists
of one or more OFDM channels. Each
OFDM channel has a PLC (PHY link
Channel) for initializing CMs (Cable
Modems). DOCSIS 3.1 is discussed in more
detail in [3], [4] and [5].
In DOCSIS 3.1, the downstream OFDM
channel is assigned a list of profiles. The
profile lists the modulation to be used for
each sub-carrier in an OFDM channel. The
profile can be different for each LDPC block
and is dependent upon which CM is
receiving the OFDM block. This is done to
allow the optimization of the transmission
path to those CMs that can tolerate a higher
modulation. The management of DOCSIS
3.1 profiles is described in [2].
The PLC Channel is composed of
message blocks (MB). The following
message blocks are defined in DOCSIS 3.1:
Timestamp MB
DLS (DOSIS Light Sleep Mode) MB
Trigger MB
Message Channel
Null MB
The timestamp MB is generated locally
at the Remote PHY. The other MBs are
transparently passed from the CCAP-Core to
the Remote PHY Entity.
In DOCSIS 3.1, the downstream and
upstream frequency ranges also can be
altered to provide more throughput. DOCSIS
3.1 can support 1 to 2.5 Gbps in the
upstream, and 5 to 10 Gbps in the
downstream. [7]
DS OFDM Channel Pseudowire
Each OFDM Channel is assigned to a
PSP pseudowire with a subtype of DOCSIS
3.1 Data Path. The PSP header is extended so
that its table contains the OFDM profile
number for each packet in the PSP stream.
DS PLC Channel Pseudowire
Each PLC is assigned to a PSP
pseudowire with a subtype of PLC. For the
DLS MB, Trigger MB and the Null MB, the
MBs are placed directly into a PSP segment
and referenced by the PSP table. A 32-bit
timestamp can optionally be prepended to a
segment. This is useful for the trigger MB.
The packets in the payload of the message
channel are mapped to PSP segments.
D3.1 Upstream Pseudowires
Figure 12 - DOCSIS 3.1 UEPI Pseudowires
There are a number of pseudowires
associated with the DOCSIS 3.1 Upstream.
All pseudowires have a pseudowire type of
PSP and each have a unique sub-type. The
DOCSIS 3.1 UEPI pseudowires are similar
to the DOCSIS 3.0 UEPI pseudowires, but
have differences in formats. The Probe PW is
unique to DOCSIS 3.1 Remote PHY.
12. Video
For video, the same Remote PHY
philosophy that was used for a DOCSIS
CMTS is applied to a video EQAM. This
works extremely well now that both the
CMTS and EQAM functionalities are
contained in the same CCAP device and use
the same PHY chip.
The video in the form of SPTS or MPTS
is received by the CCAP-Core from the
network. The CCAP core performs all the
same EQAM functions that it normally
performs. These include a jitter buffer with
PCR re-stamping, SPTS assembly into
MPTS, Conditional Access, PID remapping,
etc.
The resulting fully formatted MPTS
stream is then sent over a DEPI pseudowire
to the Remote PHY entity. Due to some jitter
that will be introduced by the network
between the CCAP-Core and the Remote
PHY entity, the Remote PHY needs to
contain a second smaller video jitter buffer.
This jitter buffer will be smaller than the one
in the CCAP-Core as it does not need to filter
server jitter.
Since video is already in MPEG-TS
format, video can be sent using a variant of
the MPT/MPT and MPT/MCM pseudowires.
The variant is that an MPEG-TS frame
counter is added in addition to the L2TPv3
sequence counter. The additional MPEG-TS
packet counter helps in error recovery.
OOB
OOB refers to the Out-of-Band protocols
that control STB operation. There are two
main OOB systems in use and they are
defined in SCTE specifications.
SCTE 55-1: This is the Motorola/Arris
system that uses MPEG-TS packets in
the downstream and an Aloha polling
system in the upstream.
SCTE 55-2: This is the SA/Cisco
system that uses ATM over a modified
T1 frame.
Analysis showed that the 55-1 system
could be implemented using the pure Remote
PHY strategy. However, the 55-2 system has
a 3 millisecond turn around time from
upstream to downstream that would of made
it extremely sensitive to network latency. As
a result, the decision was made to include the
OOB framer along with the OOB PHY in the
Remote PHY Entity. All the signaling for
OOB and the carousel generation would
remain centralized.
This also allows the OOB system to be
driven directly by provisioning systems and
OOB controllers independent of the CCAP-
Core if so desired.
OOB would use a dedicated DEPI and
UEPI pseudowire so that the links between
the CCAP-Core and the R-PHY Entity can
be reconfigured in conjunction with the other
links for DOCSIS and video.
13. REMOTE PHY TIMING
Timing in a Remote PHY Network is
managed with the Remote DTI (R-DTI)
protocol.
The goal of R-DTI is also to get
approximately the same timestamp value in
the CCAP-Core and the Remote PHY.
However, the technology for R-DTI is
completely different than the technology
used for DTI. Only the name is similar.
Whereas DTI was a local protocol that ran
over a maximum distance of 200 meters from
DTI Server to DTI Client, R-DTI is required
to work over long distances.
The R-DTI specification specifies
multiple modes of operation that provide
different levels of performance. There is a
simple low cost mode at one option and a
complete IEEE-1588 mode as another option.
R-DTI – One-Way Reverse
Figure 13 - R-DTI One-Way Reverse
The reverse direction refers to the R-
PHY Entity being a clock master and the
CCAP-Core being a clock slave.
The one-way refers to the Remote-PHY
entity sending a timestamp to the CCAP-
Core. The CCAP-Core filters the timestamp
traffic, adds a MAP advance time, and uses
the result to generate MAPs.
The advantage of the reverse method is
that the physical clock in the R-PHY Entity
does not need to be adjusted. The act of
aligning the clock in the R-PHY entity to the
CMTS-Core may cause enough disturbances
in the DOCSIS baud rate to cause the R-PHY
entity to fail the DRFI specifications. The
disadvantage of the reverse method is the
scaling required at the CCAP-Core. The
CCAP-Core may now have to track hundreds
of clocks. This, however, is not unlike what
EQAMs have to do for video dejittering.
In this method it is not known what the
delay is from the R-PHY entity to the CCAP-
Core. And maybe it does not really matter.
That delay, whatever it may be, becomes
engineering margin. The longer the network
distance, and hence the delay, the more
margin is required at the CMTS-Core. The
more jitter the network introduces, the more
margin that is required at the CMTS-Core.
So, it is somewhat of a self-compensating
mechanism.
14. R-DTI – Two-Way Reverse
Figure 14 - R-DTI Two-Way Reverse
When the CMTS-Core receives a timing
message from the R-PHY entity, it returns a
timing message, creating what is known as a
TWTT or Two-Way Time Transfer. TWTT
collects outbound and inbound timestamps in
each direction. Using these four timestamps,
the one-way network delay can be calculated.
That network delay can then managed more
precisely with the MAP advance.
There are variations on the style of
signaling as to whether or not the timestamp
from the R-PHY Entity is in the same
message as the request/response messages
that actually get stamped on ingress and
egress.
This method is superior to the one-way
reverse method only if the time stamping of
the timing packets happen in a timely and
accurate manner. Such mechanisms usually
are hardware based.
R-DTI – Two-Way Forward
Figure 15 - R-DTI Two-Way Forward
In the two-way forward mode, the
CCAP-Core is the clock master and the R-
PHY entity is the clock slave. A TWTT
protocol is run between the CCAP-Core and
the R-PHY entity.
This is the classic clocking network, and
is included to allow a full-blown level of
accuracy. This is the classic IEEE-1588
implementation. This method would be
applicable when the network is 1588
compatible.
Remote Scheduler
The Remote PHY specification permits
the relocating of the DOCSIS scheduler from
the CMTS-Core into the Remote PHY
Entity. With the scheduler remotely located,
there is no longer any timing requirement
between the CMTS Core and the Remote
PHY entity.
Although this sounds attractive at first,
there are several drawbacks to remotely
locating the scheduler. The first drawback is
that the complexity of the Remote Node
15. increases. The Remote Node entity now
become subscriber aware and requires state
information, QoS information, policy
information and needs to track historical
information for implementing of rate
shaping. This is definitely an increased level
of complexity.
The second reason that a remote
scheduler is not attractive is interoperability.
If the CCAP-Core is from one vendor, the
scheduler and node are from another vendor,
and something goes wrong, who is at fault?
How is troubleshooting done without a
centralized scheduler as a reference point?
Our current analysis shows that a
centralized scheduler will work under
currently known network conditions and that
the timing design is quite manageable. (This
will be the subject of a future white paper).
The option for a remote scheduler is a future
option should it ever be needed.
Details
Packet Formats
The two-way forward method is
intended to be an IEEE-1588
implementation. It may also include a
Synchronous Ethernet (SyncE)
implementation for frequency alignment.
The one-way and two-way reverse
methods could be implemented with a light
version of IEEE-1588 or a Remote PHY
specific control packet.
Support for DTP
DTP is the DOCSIS Timing Protocol
that was developed by this author and is
being introduced with DOCSIS 3.1. DTP
allows a CM to provide timing services such
as IEEE-1588 and Synchronous Ethernet
derived from DOCSIS timing. This is
explained in a white paper study [6] and in
the DOCSIS 3.1 specification [14].
Distances
DOCSIS define a CMTS-to-CM, PHY-
to-PHY distance of 100 miles (160 km) for
DOCSIS 3.0 and 50 miles (80 km) for
DOCSIS 3.1. Remote PHY maintains these
distances.
Because Remote PHY separates the
DOCSIS MAC and PHY, there is an
additional distance specification. That is the
MAC-to-MAC, CMTS-Core to CM distance.
This distance is relevant when the CMTS-
Core is removed from the hub and placed in
the head end or regional data center.
In theory, there is no distance limitation
to R-DTI. In practice, longer distances add
jitter and latency that may impact services
such as scheduling. While the maximum
operating distance has not been chosen at the
time this paper was written, research is being
conducted to see if R-DTI and the scheduling
applications it supports could run over a
distance up to 2000 km. This number comes
from the Indian market. The Norway market
requires about 1500 km if everything was
driven out of Oslo.
That is more than 10x the original
DOCSIS distance of 160 km!
This additional distance is intended to
allow the CCAP-Core to be located at the
head end or regional data center instead of at
the hub site.
NEXT STEPS
This white paper defined the operation
of the Remote PHY transport. The next steps
will include:
16. agreeing on the bit definition of the
various protocol headers,
extending the DEPI control plane to
cover UEPI, and
defining a configuration and
operational model for the Remote PHY
entity.
SUMMARY
Remote PHY is an approach that literally
takes the PHY chip out of a box and puts it at
the end of an IP network. One of the
philosophies of Remote PHY is to put the
least amount of hardware and software at the
end point and keep the complexity
centralized.
Remote PHY infers centralized DOCSIS
software. This allows the same software
model to be used for I-CCAP and Remote
PHY CCAP. Remote PHY, I-CMTS and M-
CMTS can all co-exist in the same chassis
and use the same software base and
configuration systems. This is a very
powerful concept for feature velocity and
backwards compatibility.
Remote PHY works and works well. The
design of remote PHY is built on top of open
standards such as Ethernet, IP, L2TPv3, and
CableLabs MHA.
Remote PHY will allow CCAP devices
to be deployed in more creative manners
such as using digital fiber in the HFC plant.
For the Cable Operators, this will allow their
network to have higher performance with
lower OPEX, lower CAPEX, and an
evolutionary path the FTTH.
REFERENCES
Related Papers by the Same Author
[1] John T. Chapman, “DOCSIS Remote
PHY,” SCTE Cable-Tec Expo, October 21,
2013
[2] John T. Chapman, “The Power of
DOCSIS 3.1 Downstream Profiles”, NCTA
Spring Technical Forum, June 13, 2013
[3] John T. Chapman, “DOCSIS 3.1 –
Redefining the State of the Art”, Cable
Congress, March 6, 2013
[4] John T. Chapman, "What the Future
Holds for DOCSIS", Keynote speech, Light
Reading Conference, Denver, May 18, 2012
[5] John T. Chapman, Robert Howald, Mike
Emmendorfer, “Mission is Possible: an
Evolutionary Approach to Gigabit-Class
DOCSIS”, NCTA Spring Technical Forum,
May 12, 2012
[6] John T. Chapman, Rakesh Chopra,
Laurent Montini, “The DOCSIS Timing
Protocol – Generating Precision Timing
Services from a DOCSIS System”, NCTA
Spring Technical Forum, June 14, 2011
[7] John T. Chapman, “Taking the DOCSIS
Upstream to a Gigabit per Second”, NCTA
Spring Technical Forum, May 12, 2010
[8] John T. Chapman, Jeff Finkelstein,
“Maximizing Legacy and DOCSIS 3.0
Bandwidth in the Forward Path using M-
CMTS and EdgeQAM Technologies”, SCTE
Cable-Tec Expo, October 30, 2009
http://www.johntchapman.com/Legacy-and-
DOCSIS3-with-M-CMTS-WP-%282009-10-
30%29.pdf
[9] John T. Chapman, “Next Generation
CMTS – An Architectural Discussion”,
17. SCTE Emerging Technologies, January 15,
2008
http://www.johntchapman.com/NG-CMTS-
WP-071125.pdf
[10]John T. Chapman, “DOCSIS Timing
Interface – Timing for DOCSIS Networks”,
National Institute of Standards and
Technology (NIST) Keynote Address, March
10, 2007
http://www.johntchapman.com/NIST-
jchapman-070310.pdf
[11]John T. Chapman, “Modular CMTS
Tutorial”, CableLabs Summit, December
2006
http://www.johntchapman.com/M-CMTS-
Tutorial-Public-070220a.pdf
[12]John T. Chapman, Andrew Page,
Carmelo Iaria, Glenn McGilvray,
“Transitioning to M-CMTS”, NCTA
National Show, April 2006
[13]John T. Chapman, “Modular CMTS
Architecture”, NCTA National Show, April
3, 2005
http://www.johntchapman.com/ncta-2005-
modular-cmts-wp.pdf
Related CableLabs Specifications
[14]“DOCSIS 3.1 MAC and Upper Layer
Protocols Interface Specification”, Revision
I02, CableLabs, March 20, 2014.
http://www.cablelabs.com/specification/mac-
and-upper-layer-protocols-interface-
specification/
[15]“DOCSIS Timing Interface (DTI)
Specification”, Revision I05, CableLabs,
December 9, 2008
http://www.cablelabs.com/specification/docsi
s-timing-interface-specification/
[16]“Downstream External PHY Interface
Specification”, Revision I08, CableLabs,
June 11, 2010
http://www.cablelabs.com/specification/dow
nstream-external-phy-interface-specification/
Related IETF Specifications
[17]David Katz, David Ward, “Bidirectional
Forwarding Detection (BFD)”, RFC-5880,
Internet Engineering Task Force (IETF),
June 2010
http://tools.ietf.org/html/rfc5880
[18]David Katz, David Ward, “Bidirectional
Forwarding Detection (BFD) for IPv4 and
IPv6”, RFC-5881, Internet Engineering Task
Force (IETF), June 2010
http://tools.ietf.org/html/rfc5881
[19]David Katz, David Ward, “Bidirectional
Forwarding Detection (BFD) for the
Pseudowire Virtual Circuit Connectivity
Verification”, RFC-5885, Internet
Engineering Task Force (IETF), June 2010
http://tools.ietf.org/html/rfc5885
[20]J. Lau, Mark Townsley, I. Goyret,
“Layer Two Tunneling Protocol – Version 3
(L2TPv3)”, RFC-3931, March 2005
http://tools.ietf.org/html/rfc3931