Mesh Network Details/lang-ko
- 참고: 기술적인 자료의 번역을 위해 여러분의 도움을 기대합니다. www.laptop.org 사이트와 이 사이트의 메인 페이지들은 대부분 번역되었으나, 나머지는 한글 요약만을 제공하고 있습니다. 어느 페이지든 추가 번역이 필요하면, XO Korea의 번역 섹션에 메시지를 남겨 주시기 바라며, 모자라는 번역 부분을 채워주실 손길을 기다리고 있습니다.
- Note: Some core pages have been fully translated, and others are provided with summaries. If you need more translation, please leave a message onto the discussion page of this, or that of XO Korea.
소개
XO 노트북과 스쿨 서버가 제공하는 메쉬 네트워킹에 관한 자세한 사항은 여기서 다루어 집니다. 뭬쉬 네트워크 FAQ도 참고하십시오.
Details of the mesh networking provided by the XO laptop and School server are provided here. See also a related Mesh Network FAQ.
디자인 목표
XO 노트북을 위한 무선 메쉬 네트워킹 인터페이스의 디자인 사양은;
- CPU가 중단인 경우에도 메쉬 포인트로 역할
- 최소한의 전력 소비
- 비대칭 링크/경로 지원
- 지속적 업그레이드
- 때가 되면, 802.11s 드래프트 준수
The design specifications for the wireless networking interface on the XO laptop include:
- Ability to act as a mesh point when laptop's main CPU is off. (Small enough to run autonomously on Marvell's 88W8388 802.11 wireless module)
- Minimize power consumption in autonomous mode.
- Support for asymmetric links/paths.
- Incremental releases -- mesh networking is needed immediately on XO. Upgrades will continue to improve functionality and adherence with standards.
- Simultaneously act as a Mesh Point as well as an infrastructure node.
- Follow 802.11s draft when possible.
표준 준수
OLPC 노트북에서 이용되는 메쉬 라우팅 프로토콜 (OLPC-Mesh)은 e 802.11 Task Group S [1]이 개발 중인 802.11s 표준에 기초합니다. 표준이 완성될 시점까지 메쉬 특정 헤더 필더가 확장된 WDS 프레임을 이용할 것입니다.
The Mesh Routing Protocol used in the OLPC laptop (OLPC-Mesh) is based on the 802.11s standard being developed by the 802.11 Task Group S [2].
OLPC-Mesh was based on the first draft produced by TGs, version 0.1. At the time of this writing, TGs is working on version 1.0 of the draft.
As we are using hardware that was designed prior to the 802.11s draft, we cannot use the new mesh frame type, identified by type = 0x3 in the Frame Control field. Instead we are using WDS frames extended with mesh specific header fields.
세대간 호환성
지금 배포될 XO들과 향후 배포될 XO간의 메쉬 네트워크 구성 호환성을 위해 확장된 WDS 프레임을 계속 지원할 것입니다. 단 하나의 노트북이라도 메쉬 내에서 확장된 WDS 프레임을 요구하면, 모든 메쉬 포인트와 포털들이 그것을 지원하기 위해 확장된 WDS 프레임으로 되돌아 갑니다.
In order to avoid forced obsolescence of XO laptops already deployed in a school, limited backwards compatibility should be an important feature of future firmware revisions. Laptops issued in previous years should mesh network peacefully with laptops issued to new classes. This compatibility may take a form similar to 802.11b/g operation --- if a single laptop requiring extended WDS frames is present on a mesh, all mesh points and portals should revert to extended WDS frames in order to support it and its brethren.
메쉬 포인트
XO 노트북은 메쉬 포인트로 역할하며, 자신이 네트워크에 접근할 때나, 다른 메쉬 포인트로부터 트래픽을 전달하는 경우 모두 와이파이 인터페이스를 이용합니다. 메쉬 네트워크는 기존의 유선 네트워크에 비해 보다 동적인 경로 선정 (라우팅) 프로토록을 요구합니다. 어떤 무선 채널을 이용할 지를 결정하는 것 조차도 메쉬에서는 더욱 어렵습니다.
In typical operation, the XO laptop is operating as a mesh point. It uses its WiFi interface to both access the network itself and to relay traffic from other mesh points. A mesh network requires a more dynamic path selection (routing) protocol than that utilized in wired networks. Even the decision of which wireless channel to use is more difficult in the mesh case.
메쉬 경로 선정과 포워딩
경로 설정 메커니즘은 802.11s 드래프트가 제안한 하이브리드 와이어리스 메쉬 프로토콜 (HWMP)의 단순화된 버전에 기초합니다. (HWMP)은 온-디맨드 라우트 발견을 프로액티브 라우팅을 위한 지원과 결합합니다.
The path selection mechanism is based on a simplified version of the Hybrid Wireless Mesh Protocol (HWMP) proposed in the 802.11s draft. HWMP combines on-demand route discovery with support for proactive routing.
Proactive routing requires the formation of a tree topology under a root node. OLPC-Mesh does not support proactive routing at this time.
On-demand path discovery is largely based on Ad-Hoc On-demand Distance Vector (AODV) routing.
Paths are built using a route request / route reply management frames. When a source node needs to transmit a frame to a destination for which no path exists, a broadcast route request (RREQ) is broadcast through the mesh. As these requests are propagated, nodes receiving them will create routes to the source node in their routing tables. These routes are termed reverse routes and are only used to forward mesh management frames. When a node receives a RREQ destined to itself, it will respond with a unicast route reply (RREP), which will be sent back to the source via reverse routes. The intermediate nodes that forward RREPs back to the source will create routes to the destination node. This routes are termed forward routes, and are the routes used to forward data frames.
라우터 장애와 복구
어느 한 프레임이 다음 번 홉 (hop)으로 전달될 수 없으면 (가령, retry의 최대 수치가 초과될 때), 프레임을 위해 이용된 라우트는 무효(invalid)로 표시됩니다. 장애 라우트가 predecessors를 가질 경우, 라우트 에러 (RERR) 관리 프레임이 라우트 소스로 전송되며, 이로써 하나의 메쉬 노드가 이웃의 커버리지 영역을 벗어난 뒤에, 라우트 회복 시간을 개선합니다.
If a frame cannot be transmitted to the next hop (i.e. when the maximum number of retries is exceeded), the route that was used for the frame is marked as invalid. If the failed route has predecessors, route error (RERR) management frames are transmitted to the source of the route. This improves the route recovery time after a mesh node leaves the coverage area of a neighbor.
제한된 브로드캐스트
RREQ/RREP는 일방 (unicast) 트래픽에서만 작동합니다.
The RREQ/RREP mechanism only works for unicast traffic. Broadcast traffic is propagated through the mesh through limited flooding. Each mesh data frame contains a unique end-to-end sequence number that is set at the source. Intermediate nodes maintain a list of recently broadcast frames indexed by this sequence number and the address of the source. This table ensures that broadcast frames are retransmitted only once.
멀티캐스트
멀티캐스트는 펌웨어 버전 5.220.9.p9 이상에서 지원됩니다.
Multicast is supported in firmware versions 5.220.9.p9 and above.
메쉬 네트워크 보안
메쉬 네트워크 운영은 와이파이 스테이션이나 애드훅 모드에 비해 추가적인 보안 문제 를 가집니다.
Mesh Point operation has some additional security implications compared to WiFi station or Ad-Hoc modes.
OLPC-메쉬 연합 알고리즘
HWMP 하에서, 하나의 메쉬 포인트는 이웃을 발견하고 피어 링크를 설정하기 위해 능동적 또는 수동적 스캐닝을 이용해야 합니다. OLPC-메쉬는 이 메커니즘을 이용하지 않습니다. 이웃은 RREQ/RREP 사이클을 통해서만 발견됩니다.
전원을 켜면 (또는 재개하면?), XO 노트북은 그 자신을 다음과 같은 방식으로 메쉬 네트워크 속에 편입시킵니다.
- 노트북은 DHCP 요청을 발행하고, 메쉬 포탈 anycast address를 위해 RREQ을 발행하며, RREP 응답을 기다리는데, 어떤 결정을 내리기 전에, 모든 세 채널들(1, 6, and 11)은 OLPC 메쉬를 위해 제시됩니다.
- 어느 한 채널이 메쉬 포탈에 대해 낮은 훕 카운트를 제공하면, 그 신호가 현저히 낮지 않은 이상 그 채녈이 선택됩니다.
- 모든 채널이 메쉬 포털에 대해 동일한 훕 카운트를 제시하면, 임의 선택이 이용됩니다.
이웃 메쉬 포인트들에 대한 인증 과정이 없으므로, 메쉬는 라우트 방해나 노드 고립 공격으로부터 보호받지 못합니다. 그러한 인증 메커니즘이 OLPC의 가이드라인 내에서 성공적으로 수행될 수 있을지는 아직 불확실합니다.
Under HWMP, a Mesh Point should use active or passive scanning to discover neighbors and establish peer links. OLPC-Mesh does not use this mechanism. Neighbors are discovered only via the RREQ/RREP cycle.
Upon power-up (resume as well?), an XO laptop will associate itself with a mesh network in the following manner:
- The laptop will issue a DHCP request, followed by a RREQ for a Mesh Portal anycast address and wait for RREP replies, on all three channels being proposed for OLPC meshes (1, 6, and 11) before making any decisions.
- If any channel provides a lower hop count to a Mesh Portal, it is selected unless its signal strength is significantly lower.
- If all channels provide the same hop count to a Mesh Portal, random selection is used.
As no authentication of neighboring mesh points is performed, the mesh is not protected against route disruption or node isolation attacks. It is unclear if such an authentication mechanism could be successfully implemented within the guidelines of OLPC.
메쉬 포탈
외부 네트워크에 연결된, 그리고 메쉬 안팎으로 트래픽을 전달하는 메쉬 포인트를 메쉬 포탈 (MPP)이라 부릅니다.
Up to now we have described the operation of Mesh Points. Mesh Points that are connected to an external network, and that forward traffic in and out of the mesh are referred to as Mesh Portals (MPP).
Mesh Points must find paths to a Mesh Portal in order to access the Internet. When multiple Mesh Portals exist in the mesh, the Mesh Point must select one of them. The way the OLPC Mesh resolves this problem is by defining a layer 2 ANYCAST MAC address (0xC027C027C027) that will be claimed by all the MPPs in the mesh. When a Mesh Point needs to find an MPP, a RREQ is sent for that special ANYCAST address. Each Mesh Portal receiving the RREQ will generate a RREP. The path selection method in the firmware will assign higher precedence to those MPPs that can be reached through lower cost routes.
The Mesh Point then sends a UDP datagram to the selected mesh portal, which also replies with a datagram. In order to generate the ANYCAST message, a static binding is made in the Mesh Point ARP table between an arbitrary MPP IP address (172.31.255.254 is currently used) and the ANYCAST MAC address. Then a UDP message is composed to the MPP IP address and MPP service port (currently 16), containing the contents "MPPREQ".
Mesh Portals must bind the MPP IP address (172.31.255.254) to one of their network interfaces, and listen for configuration requests sent by Mesh Points to that address on the MPP service port (16). In reply to these requests, Mesh Portals will send to the Mesh Points all the information required to access outside the mesh network. At this time this configuration information is comprised of the IP address of the selected Mesh Portal and the addresses of DNS servers.
More information about this configuration daemon can be found:
Traffic forwarding in and out of the mesh is done at layer 3 via Network Address Translation (NAT) at the host. This gives the flexibility to use any other network connection to connect the mesh to the world (e.g. PPP, GPRS, etc.).
드라이버 인터페이스
무선 드라이버는 메쉬 트래픽을 위한 가상 네트워크 인터페이스를 만듭니다 (sh0 on the laptop). 노트북이 AP에 연결될 때는 메인 인터페이즈 (노트북에서는 주로 eth0)이 인프라스트럭처 트래픽을 위해 이용됩니다. 이것은 또한 MAC 주소 할당과 같은 현재 메쉬 인터페이스에서 지원되지 않는 컨트롤 오퍼레이션을 위해서도 이용됩니다.
The wireless driver creates a virtual network interface just for mesh traffic (msh0 on the laptop). The main interface (usually eth0 on the laptop) is used for infrastructure traffic when the laptop is associated to an AP. It is also used for some control operations that aren't currently supported by the mesh interface, such as assigning a MAC address.
유저스페이스 컨트롤
OLPC-메쉬의 행동을 검사하고 수정하는데 이용될 수 있는 여러가지 시스템 콜이 있습니다. 이 콜들은 ioctls에 의해 수행되고, iwpriv 명령에 의해 깨워집니다.
There are several system calls available to examine and modify the behavior of the OLPC-Mesh. This calls are implemented as ioctls, and can be invoked via iwpriv commands.
The first of such tools are the
iwpriv fwt_*family of commands. With these commands one can examine and modify the routing table. See the Wireless Driver README file in the libertas driver directory for details.Another useful feature for debugging and testing is the blinding table. Incoming traffic from any address that exists in the blinding table will be silently discarded by the firmware. This is useful to test specific mesh topologies that would otherwise be hard to setup. The blinding table can be accessed using
iwpriv bt_{add,del,reset,list}.There is also one ioctl call that will change the maximum TTL of outgoing mesh traffic. The TTL determines the maximum number of hops that a frame will cross before being dropped. This is used to minimize the consequences of routing loops but it also limits the number of neighbors that can be reached in the mesh. The mesh TTL can be modified via
iwpriv mesh_{get,set}_ttl.Finally, there are mesh specific statistics available through
ethtool -SCurrently the following counters are implemented:drop_duplicate_bcast drop_ttl_zero drop_no_fwd_route drop_no_buffers fwded_unicast_cnt fwded_bcast_cnt drop_blind_table tx_failed_cnt
주석
[1] Note that although the frame is discarded, it will still be acknowledged by the MAC layer.