1. Topology(모양)

- ①Bus topology: linear transmission medium으로 양쪽 끝에 저항을 달아 신호(frame)가 되돌아가지 않도록 되어 있는 구조
- 동시에 여러 개의 frame을 전달할 수 없으므로 멀티플렉싱(FDM or TDM)과 MAC(Medium Access Control, 접근 권한 획득) 필요
- 신호가 갈 수 있는 거리의 제한이 있음
- 만약 중간이 끊긴다면 전부 통신이 불가함
- ②Star topology: 전체를 관장하는 central hub가 있고, 그 central hub에 여러 개의 node가 달려있는 구조
- node가 다시 central hub의 역할을 하는 형태로 계층구조로 확장할 수 있음
- 한 번에 한 명만 보내게 할 수도 있음(Ex. bus)
- 또한, 동시에 여러 개의 node가 서로 통신할 수 있도록 함(switch가 있다면)
- IEEE 802.4에서는 token bus → 802.5에서는 token ring
- → IEEE 802 중 data-link layer에 속하는 일: data-link layer = LLC + MAC
- LLC(logical link control): 상위 계층으로의 interface 제공, flow and error control
- MAC(Meidum Access Control): 조립 가능한 frame으로 데이터 전송, 조립할 수 없는 frame이나 에러 detect, 주소 인식, LAN 전송 매체로의 접근 관리 → LAN protocl은 MAC layer에서 encapsulation한 frame이 전송되는 것

2. LLC(Local Link Control)
- must support multi-access and shared medium
- MAC layer를 위한 link access
- ①acknowledged connectionless service: ACK을 보냄, 논리적인 연결 설정이 없음
- ②unacknowledged connectionless service: ACK을 보내지 않음 → not guaranteed, 논리적인 연결 설정이 없음, data-gram style
- ③connection-mode service: 논리적인 연결 설정이 있음, flow and error control
- → 망 자체는 connectionless지만 connection인것처럼 service를 하겠음 like packet switching(물리적 연결 없음)
- vs 이더넷: error control 없음 → error는 그냥 버림
- asynchronous systems: round robin: 각각의 station이 데이터를 전송할 수 있는 기회를 얻음, reservation: medium이 slot으로 나뉨 & stream traffic에게 유용, contention(star topology에서 '나 전송해야해' 하고 central hub에게 알려야하는데 이때 경쟁이 발생함 → 경쟁에서 이긴 node에게 ACK을 보냄): bursty traffic에 적합 & 심플
3. MAC(Medium Access Control)
- LAN segment끼리 MAC이 다를수도 있음 → bridge 사용(양쪽 변환 but 상위 계층은 같아야 함 vs repeater: 양쪽이 상위 계층까지 같아야 함 vs gate-way: 상위 계층까지 프로토콜이 다를 때)
- bridge: table을 스스로 만들어가는 self learning but loop가 발생하면 논리적으로 tree형태로 만드는데 이때 바로 보낼 수 있더라도 optimal route(이것을 찾는건 router의 역할?)를 찾지 못함 즉, 빙빙 둘러가야 한다~ 그러나 속도를 엄청 빠르게 한다면 문제될게 없지 않을까?
- Q. how self-learning?
- A. 밑에 애들한테 다 보내보거나 or 밑에 애들이 source가 될 때 알 수 있음
- Ex)
- host 1이 host 2에게 데이터를 보내고 싶을 때, host 1이 bridge로 frame을 보냄
- → bridge는 port A로 들어온 frame을 통해 port A가 host 1과 연결되어 있다는 걸 알게 됨 → table에 작성: source가 된 경우
- but host 2는 어디에 있는지 모르기 때문에 모든 port로 frame을 보내는 flooding을 함: 밑에 애들한테 다 보내는 경우
- → port B와 연결된 host 2가 frame을 받고 host 1에게 답장을 보냄 → 이때 table에 port B와 host 2가 연결되어 있다고 작성: source가 되는 경우

- Q. bridge loop는 있으면 왜 안됨?
- A. frame이 끝없이 loop를 돌기 때문
- Ex)
- host 1에서 host 2로 frame을 보낼 때 bridge에는 아직 table이 미완성이라서 일단 port A가 host 1과 연결되는 거라고 table 작성
- → 그 후 host 2를 모르니까 모든 port로 frame을 보내서 host 2로 돌아오는 답변으로 host 2의 위치를 알아내려는데, 좌측 bridge도 우측 bridge도 port C를 통해서 host 1이 보낸 frame을 host 2에게 전달하지만 그와 동시에 서로(bridge끼리)에게도 전달함
- → 각 bridge는 port C로부터 host 1이 보낸 frame을 받은 셈이니까 host 1이 port C와 연결되어 있다고 table을 잘못 업데이트 함

4. Swtich
- ①store-and-forward switch: frame을 input line에서 받아서 buf에 넣고 output line으로 내보냄 → delay 발생
- ②cut-through switch: frame의 시작부분에 있는 destination address를 사용하여 buf에 넣지 않고 바로 output line으로 내보냄 but 잘못 보낼 가능성도~
- vs bridge

- LAN은 외부인 internet은 router로 연결하고 내부적으로는 swtich끼리 연결되어 있지만 논리적으로 구분할수도 있다람쥐 → VLAN
- VLAN(Virtual Local Area Network): 논리적으로 구분되어 있음, 구분의 기준은 동일한 LAN segment 즉, 브로드캐스팅시에 도메인에 있는 범위로 IEEE 802.1Q에 정의 되어 있다뤼
+) Ref
https://blackinkgj.github.io/Bridge/
http://www.ktword.co.kr/test/view/view.php?m_temp1=2127