12.8 CCCs

Up to now, this chapter has focused on MPLS and the use of LDP and RSVP in an MPLS implementation. It also showed how LDP is used in most non-traffic-engineering scenarios, and how RSVP can be used in both MPLS LSP establishment and traffic engineering. This section introduces CCCs, or circuit cross connects, and how they are applied to the traffic-engineering model.

CCC is not directly related to MPLS and its operation, at least in the same regard as LDP or RSVP. However, there are certain functions of CCC that can be used with MPLS LSPs to further enhance traffic-engineering capabilities. CCC is a proprietary function of JUNOS and will not interoperate with other vendors ' systems.

CCC is a tool used to map two Layer 2 circuits of the same type within a router to each other. This functionality expands JUNOS-based routers from typical Layer 3 operations to perform Layer 2 switching. This functionality offers the ability to perform essential flow functions without having to go through a series of decapsulation and encapsulation functions first. This means that flow control functions can be processed at Layer 2, versus having to decapsulate the Layer 2 frame, analyze the Layer 3 information, encapsulate back to Layer 2, then forward. CCC also yields the ability to switch frames from inbound interfaces to outbound interfaces based on predetermined Layer 2 associations. The Layer 3 header is never examined.

There are three types of cross connects supported by JUNOS:

1. Layer 2 switching ”can only be performed on logical interfaces such as Frame Relay DLCIs, ATM virtual circuits, Ethernet VLANs, and PPP interfaces

2. MPLS tunneling ”takes advantage of being able to connect to nonlocal circuits of the same interface type by creating an MPLS tunnel between the two systems

3. LSP stitching ”allows two LSPs that terminate on one given router to be stitched together

All Layer 2 and MPLS tunneling functions are bidirectional in nature. This is due in part to how the cross connects are created. LSP stitching, on the other hand, is unidirectional. As was mentioned in Section 12.3.1.2, LSPs are created in a unidirectional manner; thus, two LSPs would be needed for bidirectional communication between networks residing on the ingress and egress routers.

Figure 12-11 illustrates this concept. It shows a simple scenario using Frame Relay interfaces. Routers Chicago and New York can be any customer router using Frame Relay to connect to router San Francisco. With CCC it is possible to cross connect DLCI 201 to 203 in router San Francisco. This would eliminate having to extract Layer 3 packets from the Frame Relay frame and make a Layer 3 decision, encapsulate back to Frame Relay, and send out to New York.

Figure 12-11. MPLS and CCC Sample Topology

In Figure 12-11, PPP, ATM VCs, Cisco HDLC, or VLANs could have easily been used as the Layer 2 technology instead of Frame Relay. The point here is that in certain scenarios, CCC can become a more efficient method of forwarding. It is important to reiterate that when using CCC, the circuit types must be the same. For example, it is not possible to build a CCC between a Frame Relay link with DLCI 201 and an ATM link with a VC 203.

CCC works with Layer 2 of the OSI model. If Layer 3 addressing is on the interface being used for CCC, then the configuration will not commit. The following example shows the CCC configuration sample necessary to establish the connection.

  [edit protocols connections interface-switch Chicago-NewYork]  lab@SanFran#  set interface at-1/2/1.100  [edit protocols connections interface-switch Chicago-NewYork] lab@SanFran#  set interface at-1/2/0.100  [edit protocols connections interface-switch Chicago-NewYork] lab@SanFran# up [edit protocols connections] lab@SanFran# show  interface-switch Chicago-NewYork {   interface at-1/2/1.100;   interface at-1/2/0.100;  } 

In addition to the CCC connection configuration, it is necessary to specify under the interface the type of encapsulation for the logical unit.

The next example shows configuring the switch interface on the router doing the switching:

  [edit interfaces]  lab@SanFran#  set interface-switch frame-relay-ccc  [edit interfaces] lab@SanFran# edit so-1/0/0 unit 0 [edit interfaces so-1/0/0 unit 0] lab@SanFran#  set encapsulation frame-relay-ccc  [edit interfaces so-1/0/0 unit 0] lab@SanFran# exit [edit interfaces] lab@SanFran# show  interface-switch frame-relay-ccc;   so-1/0/0 {  unit 0 {         point-to-point;  encapsulation frame-relay-ccc;  dlci 501;     } }