Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Both the PE and CE devices are normally either IP routers or label switch<strong>in</strong>g routers (i.e., the<br />
latter supports MPLS, and the former supports traditional IP IGP and EGP rout<strong>in</strong>g). The labels<br />
r3, r4, r5, and r6 <strong>in</strong> figure 34 represent IP routers that are <strong>in</strong>ternal to the customer site. The IPsec<br />
variant [99] of RFC 4364 that is used <strong>in</strong> this architecture is described as follows:<br />
“In BGP/MPLS IP Virtual Private <strong>Networks</strong> (VPNs), VPN data packets travel<strong>in</strong>g<br />
from one Provider Edge (PE) router to another generally carry two MPLS labels,<br />
an “<strong>in</strong>ner” label that corresponds to a VPN-specific route, and an “outer” label<br />
that corresponds to a Label Switched Path (LSP) between PE routers. In some<br />
circumstances, it is desirable to support the same type of VPN architecture, but<br />
us<strong>in</strong>g an IPsec Security Association <strong>in</strong> place of that LSP. The “outer” MPLS<br />
label would thus be replaced by an IP/IPsec header. This enables the VPN<br />
packets to be carried securely over non-MPLS networks, us<strong>in</strong>g standard IPsec<br />
authentication and/or encryption functions to protect them.” [99]<br />
r3<br />
CE2<br />
r5<br />
r4<br />
CE1<br />
PE1<br />
PE1<br />
CE3<br />
r6<br />
Customer<br />
Site 1<br />
Service<br />
Provider(s)<br />
Customer<br />
Site 2<br />
Figure 34. The VPN Interconnect<strong>in</strong>g Two Sites (copy of Figure 1.1 of RFC 4110)<br />
The specific implementation proposed <strong>in</strong> this report’s design has def<strong>in</strong>ed an encapsulation<br />
gateway middlebox (RFC 3234) that performs the functions of both the CE and PE <strong>in</strong>terfaces of<br />
figure 34 for each specific software level VPN community. For example, if an airplane has four<br />
different software level communities, then there will be four dist<strong>in</strong>ct encapsulat<strong>in</strong>g gateway<br />
devices on that airplane, one for each software level community. The encapsulation gateway,<br />
therefore, operates exactly like the COMSEC device <strong>in</strong> figure 17 and the <strong>in</strong>terface <strong>in</strong> figures 20<br />
and 22. The VPN technology recommended by this study uses ubiquitously available IPsec<br />
technology. However, VPN scalability itself is achieved by adopt<strong>in</strong>g proven IETF L3VPN<br />
BGP/MPLS techniques. The IPsec variant of BGP/MPLS, which this study recommends, is not<br />
as widely deployed today as its BGP/MPLS parent technology. The deployments that do exist<br />
primarily (probably exclusively) implement the IPsec approach via routers. There are two<br />
reasons this study recommends develop<strong>in</strong>g an encapsulation gateway middlebox rather than<br />
110